MCSA Windows Server 2012 R2 Administration Study Guide Exam 70-411 (2015)

THE FOLLOWING 70-411 EXAM OBJECTIVES ARE COVERED IN THIS CHAPTER:

1. Configure VPN and routing

§ Install and configure the Remote Access role

§ Implement Network Address Translation (NAT)

§ Configure VPN settings

§ Configure remote dial-in settings for users

§ Configure routing

§ Configure Web Application proxy in passthrough mode

2. Configure DirectAccess

§ Implement server requirements

§ Implement client configuration

§ Configure DNS for DirectAccess

§ Configure certificates for DirectAccess

Now that you understand how routing works, it’s time to discuss how clients connect using remote access. Routing and Remote Access Services (RRAS) includes some security features necessary to provide remote access effectively. For example, you’ll probably want the ability to restrict user dial-up access by group membership, time of day, or other factors. You’ll also need a way to specify the various callback, authentication, and encryption options that the protocols support.

In this chapter, you’ll learn about virtual private networks (VPNs), which provide remote access to private networks across public connections. That is, using the Internet, clients can dial in to an Internet service provider (ISP) and connect to your private network. The main benefit of VPNs is reduced cost because it means that long-distance calls are unnecessary. VPNs are becoming more popular because of the increased popularity of high-speed Internet connections, such as cable and digital subscriber line (DSL) connections.

Many of the features included in Windows Server 2012 R2 are simply carried over from Windows Server 2008, with a few minor additions. This is the case with the Routing and Remote Access console.

Before I can get into the details of what these features do and how to configure them to provide remote access for your network, you need to understand some of the terms and concepts specific to RRAS. That’s where you’ll begin in this chapter, and then you’ll move on to learning about the features and configuration settings that you need to understand to meet the exam objectives.

Overview of Dial-Up Networking

LANs provide relatively high-speed connectivity to attached machines, but where does that leave those of us who work from home, who travel, or who need to access data on a remote computer? Until wireless access is available worldwide, we have the option of using dial-up networking in which the client computer uses a modem to dial in and connect to a remote server. Once the connection is established, a variety of protocols and services make it possible for us to view web pages, transfer files and email, and do pretty much anything we could do with a hardwired LAN connection, albeit at a reduced speed.

In the following sections, you will learn more about what dial-up networking does and how it works by examining the specific technologies and protocols associated with remote access.

What DUN Does

At this point in the book, you should understand that Windows Server 2012 R2 network protocols are actually implemented as drivers. These drivers normally work with hardware network interfaces to get data from point A to point B. How do dial-up connections fit in? Many people may read this and say, “Who still uses dial-up?” Well, as a person who lives in New Hampshire, I can tell you that we still have many areas that can’t get broadband or even satellite access.

Think back to the OSI model. Each layer has a function, and each layer serves as an intermediary between the layer above it and the one below it. By substituting one driver for another at some level in the stack, you can dramatically change how things work. That’s exactly what the Windows Server 2012 R2’s Dial-Up Networking (DUN) subsystem does. It makes the dial-up connection appear to be just another network adapter.

The DUN driver takes care of the task of making a slow asynchronous modem appear to work just like a fast LAN interface. Applications and services that use TCP/IP on your DUN connection never know the difference. In fact, you can configure Windows Server 2012 R2 to use your primary connection first and then to pass traffic over a secondary connection (such as a dial-up link) if the primary connection is down. This does not affect the applications with which you’re working (except that they might run more slowly).

On the server side, DUN allows you to host one or more network users who dial into your Windows Server 2012 R2 machine. Windows XP Professional, Windows Vista, Windows 7, and Windows 8 all allow up to 10 concurrent dial-up connections, and Windows Server 2012 R2 allows up to 255. (Be aware that by the time you allow 255 concurrent connections, you’ll probably be overloading your server.)

Depending on how you configure the DUN server, users who dial in can see the whole network or only specific resources on the server. You also get to control who can log on, when they can log on, and what they can do once they’ve logged on. As far as Windows Server 2012 R2 is concerned, a user connected via DUN is no different from one using resources over your LAN, so all the access controls and permissions you apply remain in force for DUN users.

How DUN Works

A lot of pieces are required to complete a dial-up call successfully from your computer to a server at another physical location. Understanding what these pieces are, how they work, and what they do for you is important. The following sections will cover the DUN infrastructure, how the Point-to-Point Protocol (PPP) helps with this connection, the relationship between PPP and the network protocols, and how multilink can be used to increase the speed and efficiency of your remote connections.

The DUN Infrastructure

This section covers the physical layer that underlies voice and data calls. Most of the following material will be familiar to anyone who has ever used a modem, but you should still understand the details you may not have considered before.

Plain Old Telephone Service

Plain Old Telephone Service (POTS) connections offer a theoretical maximum speed of 56Kbps; in practice, many users routinely get connections at 51Kbps or 52Kbps.

The word modem is actually short for modulator-demodulator. The original Bell System modems took digital data and modulated it into screechy analog audio tones suitable for use on regular phone lines. Because phone lines are purposely designed to pass only the low end of the audible frequency range that most can hear, the amount of data was limited. However, in the early 1990s, an engineer discovered that you could communicate much faster when the path between the sender and receiver was all digital.

An all-digital path doesn’t have any analog components that induce signal loss, so it preserves the original signal quality faithfully. This in turn makes it possible to put more information into the original signal. As it happens, phone companies nationwide were in the process of making major upgrades to replace their analog equipment with newer and better digital equivalents. These upgrades made it possible for people in most areas to get almost 56Kbps speeds without changing any of the wiring in their homes or offices. The connection between the house and the phone office was still analog, but the connections between phone offices were digital, ensuring high-quality connections.

Integrated Services Digital Network

In the mid-1970s, Integrated Services Digital Network (ISDN) was designed. At the time, no one had any idea that you’d be able to get 56Kbps speeds out of an ordinary phone line. ISDN speeds of up to 128Kbps over a single pair of copper wires seemed pretty revolutionary. In addition, ISDN had features such as call forwarding, caller ID, and multiple directory numbers (so you could have more than one number, perhaps with different ringing patterns, associated with a single line).

Unfortunately, ISDN requires an all-digital signal path. It also requires special equipment on both ends of the connection. The phone companies were slow to promote ISDN as a faster alternative to regular dial-up service, so customers avoided it.

ISDN still has some advantages, though. Because it’s all digital, call setup times are much shorter than they are for analog modems—it takes only about half a second to establish a new ISDN call. Modern ISDN adapters and ISDN-capable routers can seamlessly stitch together multiple ISDN channels to deliver bandwidth in 64Kbps increments. Because you can use ISDN lines for regular analog voice, data, and fax traffic, you can make a single ISDN act like two voice lines, a single 128Kbps data line, or a 64Kbps data line plus a voice line.

ISDN is quickly being replaced by faster broadband services such as DSL and cable modems. In fact, you should resort to ISDN only if these other solutions are not available in your area. Note that DSL (a misnomer because they are all digital) and cable modems do not use PPP (discussed later), so they are technically not considered dial-up connections.

Other Connection Methods

Any other on-demand connection that’s established using the Point-to-Point Protocol can be thought of as a dial-up connection, and Windows Server 2012 R2 doesn’t make any distinction between POTS, ISDN, and other dial-ups—they’re all treated identically.

Connecting with PPP

The Point-to-Point Protocol enables any two devices to establish a TCP/IP connection over a serial link. That usually means a dial-up modem connection, but it could just as easily be a direct serial cable connection, an infrared connection, or any other type of serial connection. When one machine dials another, the machine that initiates the connection is referred to as a client, and the machine that receives the call is referred to as a server—even though PPP itself makes no such distinction.

PPP negotiation involves three phases that are required to establish a remote access connection. Actually, at least six distinct protocols run on top of PPP. Understanding what they do helps to make the actual PPP negotiation process clearer. These protocols are as follows:

The Link Control Protocol The Link Control Protocol (LCP) handles the details of establishing and configuring the lowest-level PPP link. In that regard, you can think of LCP as if it were almost part of the Physical layer. When one PPP device calls another, the devices use LCP to agree that they want to establish a PPP connection.

The Challenge Handshake Authentication Protocol The Challenge Handshake Authentication Protocol (CHAP)—as well as MS-CHAPv2 and PAP—allow the client to authenticate itself to the server. This authentication functions much like a regular network logon; once the client presents its logon credentials, the server can figure out what access to grant.

The Callback Control Protocol The Callback Control Protocol (CBCP) is used to negotiate whether a callback is required, whether it’s permitted, and when it happens. Once the client has authenticated itself, the server can decide whether it should hang up and call the client back. The client can also request a callback at a number it provides. Although this isn’t as secure as having the server place a call to a predetermined number, it provides some additional flexibility. If a callback occurs, the connection is reestablished and reauthenticated, but the CBCP stage is skipped.

The Compression Control Protocol The Compression Control Protocol (CCP) allows the two sides of the connection to determine what kind of compression, if any, they want to use on the network data. Because PPP traffic actually consists of wrapped-up IP datagrams and because IP datagram headers tend to be fairly compressible, negotiating effective compression can significantly improve overall PPP throughput.

The IP Control Protocol At this point in the call, the two sides have agreed to authentication, compression, and a callback. They haven’t yet agreed on what IP parameters to use for the connection. These parameters, which include the maximum packet size to be sent over the link (the maximum transmission unit, or MTU), have a great impact on the overall link performance, so the client and server use the IP Control Protocol (IPCP) to negotiate them based on the traffic they expect to be passed.

The Internet Protocol Once the IPCP negotiation has been completed, each end has complete knowledge of how to communicate with its peer. That knowledge allows the two sides to begin exchanging Internet Protocol (IP) datagrams over the link, just as they would over a standard LAN connection.

The Relationship Between PPP and Network Protocols

Usually, when you hear about network communication, you hear about using TCP/IP on a hardwired LAN. How does this protocol fit in with PPP? In the case of TCP/IP, that’s an easy question to answer: The client routes all (or some) of its outgoing TCP/IP traffic to its PPP peer, which can then inspect the IP datagrams it gets back from the PPP stack to analyze and route them properly.

Windows Server 2012 R2 supports only TCP/IP, so consider what has to happen when a client using AppleTalk needs to connect via dial-up. Because the server will not use those other protocols, it will drop the call or cause the client to warn its user (that’s what Windows Server 2012 R2 does). After the other PPP setup steps are finished, the client and server can wrap other types of network traffic inside an IP datagram. This process, called encapsulation, allows the client to take a packet with some kind of private content, wrap it inside an IP datagram, and send it to the server. The server, in turn, processes the IP datagram, routing real datagrams normally and handling any encapsulated packets with the appropriate protocol. At that point, the client can communicate with the server without knowing that its non-TCP/IP packets are being encapsulated in any way—that detail is hidden deep in the layers of the OSI model.

Understanding the Benefits of Multilink

Many parts of the world don’t have high-speed broadband access yet. In fact, many places don’t have ISDN or even phone lines that support 56Kbps modems. The multilink extensions to the Point-to-Point Protocol provide a way to take several independent PPP connections and make them look like one line so that they act as a single connection.

For example, if you use two phone lines and modems to place a two-line multilink call to your ISP, instead of getting the usual 48Kbps connection, you would end up with an apparent bandwidth of 96Kbps. The multilink PPP software on your Windows Server 2012 R2 machine and on the ISP’s router takes care of stringing all of the packets together to make this process seamless. Windows Server 2012’s RRAS supports multilink PPP for inbound and outbound calls.

The primary drawback to multilink calls is that they take up more than one phone line apiece.

Overview of Virtual Private Networks

Private networks offer superior security. You own the wires, so you have control over what they’re used for, who can use them, and what kind of data passes over them. However, they’re not very flexible because they require you to configure and manage costly leased lines between remote locations. To make things worse, most private networks face a dilemma: Implementing enough capacity to handle peak loads almost guarantees that much of that capacity will remain idle much of the time, even though it still has to be paid for.

One way to work around this problem is to maintain private dial-up services. Such services allow, for example, a field rep in Chicago to dial into the home office in Boston. But dial-ups are expensive, and they have the same excess capacity problem as truly private networks. As an added detriment, someone has to pay long-distance or toll-free number charges.

Virtual private networks (VPNs) offer a solution. You get the security of a true private network with the flexibility, ubiquity, and low cost of the Internet. In the following sections, I will cover VPNs, including what they are used for and how they work (in general and with Windows Server 2012).

What VPNs Do

At any time, two parties can create a connection over the Internet. The idea behind a VPN is that you can use these connections to let two parties establish an encrypted tunnel between them using the Internet as a transportation medium. The VPN software on each end takes care of encrypting the VPN packets as they go; when the packets leave one end of the tunnel, their payloads are encrypted and encapsulated inside regular IP packets that cause them to be delivered to the remote machine. Figure 4.1 shows one way to conceptualize this process.

FIGURE 4.1 Drilling a tunnel through the Internet

As an example, let’s say you’re in the field at a client site. As long as you’re somewhere that your ISP serves, you can dial into the client’s local point of presence and get connected to the Internet. At that point, you can open a VPN connection back to the servers at your office and do whatever you could do when sitting in front of a regular desktop machine.

VPNs and Windows Server 2012 R2

Windows Server 2012 R2 includes support for Microsoft’s proprietary Point-to-Point Tunneling Protocol and Layer 2 Tunneling Protocol. Layer 2 Tunneling Protocol (L2TP) provides a more generic tunneling mechanism than PPTP, and when combined with IPsec, L2TP also allows you to establish VPNs using a wide range of Microsoft or non-Microsoft hardware and software products, including routers and access devices from companies such as Cisco, Red Creek, and Nortel.

Windows Server 2012 R2’s VPN support includes the following worthwhile features:

§ You can set up account lockout policies for dial-up and VPN users. This capacity has existed for network and console users for some time.

§ The Extensible Authentication Protocol (EAP) allows Microsoft or third parties to write modules that implement new authentication methods and retrofit them to servers. One example is the EAP-TLS module, which implements access control based on smart cards and certificates for VPN and dial-up users.

How you enable VPN support on your Windows Server 2012 R2 machine depends on whether you’re using a server or a client (Windows XP, Windows Vista, Windows 7, Windows 8, and so on).

Client configuration is easy. Just install the Dial-Up Networking service and then use the Make New Connection Wizard to create a new VPN connection. On the server side, you’ll need to install and configure RRAS and then enable it to accept incoming VPN connections.

How VPNs Work

The VPN client assumes that the VPN server is already connected to the Internet in some way. Here’s how the VPN connection process works:

1. The client establishes a connection to the Internet. Dial-up networking or any other connection method can be used for this connection. The client must be able to send packets to the Internet.

2. The client sends a VPN connection request to the server. The exact format of the request varies, depending on whether the VPN is using PPTP, L2TP, or SSTP.

3. The client authenticates itself to the server. Again, the exact process varies according to the VPN protocol in use. If the client can’t provide valid credentials, the connection is terminated.

4. The client and server negotiate parameters for the VPN session. This negotiation allows the two ends to agree on an encryption algorithm and strength.

5. The client and server go through the PPP negotiation process because both L2TP and PPTP depend on the lower-level PPP.

Because the contents of data passed around in step 2 and step 3 vary according to the tunneling protocol in use, I’ll explain the differences. First, though, you should understand encapsulation and how VPNs use it to wrap one kind of data inside another.

An Encapsulation Primer

Most of yesterday’s networks could carry only one kind of data. Each network vendor had its own protocol, and most of the time there was no way to intermingle data using different protocols on the same line. Over time, vendors began to find ways to allow a single network to carry many different types of traffic, resulting in the current assortment of traffic types found on most large networks. However, the Internet works only with IP, which is why it’s called Internet Protocol. If you need to send other types of traffic, such as AppleTalk, across the Internet, you can encapsulate it within IP.

How does encapsulation work? Software at each level of the OSI model has to see header information to figure out where a packet is coming from and where it’s going. However, the payload contents aren’t important to most of those components, and the payload is what’s encapsulated. By fabricating the right kind of header and prepending it for whatever you want in the payload, you can route foreign traffic types through IP networks with no trouble.

VPNs depend on encapsulation because their security method depends on being able to keep the payload information encrypted. The following steps demonstrate what happens to a typical packet as it goes from being a regular IP datagram to a PPTP packet (seeFigure 4.2).

FIGURE 4.2 The encapsulation process

1. An application creates a block of data bound for a remote host. In this case, it’s a web browser.

2. The client-side IP stack takes the application’s data and turns it into an IP packet, first by adding a TCP header and then by adding an IP header. This is called the IP datagram because it contains all of the necessary addressing information to be delivered by IP.

3. The client is connected via PPP, so it adds a PPP header to the IP datagram. This PPP+IP combination is called a PPP frame.

4. If you are using PPP instead of a VPN protocol, the packet goes across the PPP link without further modification. When you are using a VPN (as in this example), the next step is for the VPN to encrypt the PPP frame, turning it into unreadable information to be transported over the Internet.

5. A Generic Routing Encapsulation (GRE) header is combined with the encrypted payload. GRE really is generic; in this case, the protocol ID field in the GRE header says that this is an encapsulated PPTP packet.

6. Now that there is a tag to tell you what’s in the payload, the PPTP stack can add an IP header (specifying the destination address of the VPN server) and a PPP header.

7. Now the packet can be sent out over your PPP connection. The IP header specifies that it should be routed to the VPN server.

8. When the packet arrives at the VPN server, the server reverses steps 1 through 6 to extract the payload.

Encapsulation allows the use of VPN data inside ordinary-looking IP datagrams, which is part of what makes VPNs so powerful—you don’t have to change any of your applications, routers, or network components (unless they have to be configured to recognize and pass GRE packets).

PPTP Tunneling

PPTP is a pretty straightforward protocol. It works by encapsulating packets using the mechanism described in the previous section, “An Encapsulation Primer,” and performs encryption (step 4) using the Microsoft Point-to-Point Encryption (MPPE) algorithm. The encryption keys used to encrypt the packets are generated dynamically for each connection; in fact, the keys can be changed periodically during the connection.

When the client and server have successfully established a PPTP tunnel, the authorization process begins. This process is an exchange of credentials that allows the server to decide whether the client is permitted to connect:

1. The server sends a challenge message to the client.

2. The client answers with an encrypted response.

3. The server checks the response to see whether the answer is right. The challenge-response process allows the server to determine which account is trying to make a connection.

4. The server determines whether the user account is authorized to make a connection.

5. If the account is authorized, the server accepts the inbound connection; any access controls or remote access restrictions still apply.

L2TP/IPsec Tunneling

L2TP is much more flexible than PPTP, but it’s also more complicated. It was designed to be a general-purpose tunneling protocol not limited to VPN use.

L2TP itself doesn’t offer any kind of security. When you use L2TP, you’re setting up an unencrypted, unauthenticated tunnel. Using L2TP by itself over the Internet, therefore, would be dangerous because anyone who wanted to could read your traffic.

The overall flow of an L2TP/IPsec tunnel session looks a little different from that of a PPTP session because IPsec security is different. Here’s how the L2TP/IPsec combination works:

1. The client and server establish an IPsec security association using the ISAKMP and Oakley protocols. At this point, the two machines have an encrypted channel between them.

2. The client builds a new L2TP tunnel to the server. Because this happens after the channel has been encrypted, there’s no security risk.

3. The server sends an authentication challenge to the client.

4. The client encrypts its answer to the challenge and returns it to the server.

5. The server checks the challenge response to see whether it’s valid; if so, the server can determine which account is connecting. At this point, the server can accept the inbound connection, subject to whatever access policies you’ve put in place.

Note that steps 3 through 5 mirror the steps described for PPTP tunneling. This is because the authorization process is a function of the remote access server, not the VPN stack. All the VPN does is to provide a secure communications channel, and something else has to decide who gets to use it.

SSTP Tunneling

The Secure Sockets Tunneling Protocol (SSTS) is a secure way to make a VPN connection using the Secure Sockets Layer v.3 (SSL) port 443. The following steps show how SSTP operates and functions:

1. The client connects to the server through the Internet using port 443.

2. During the TCP session, SSL negotiation takes place.

3. During the SSL authentication phase, the client machine receives the server certificate.

4. The client machine will send HTTPS requests on top of the encrypted SSL session.

5. The client machine will then also send SSTP control packets on top of the HTTPS session.

6. PPP negotiation now takes place on both ends of the connection.

7. After PPP is finished, both ends are ready to send IP packets to each other.

Configuring Your Remote Access Server

Most of the configuration necessary for a remote access server happens at the server level. You use the server’s Properties dialog box to control whether the server allows remote connections, what protocols and options it supports, and so forth. Because all of the protocols are carried via PPP, you can set some generic PPP options as well. I will cover these options in the following sections. You also have to configure settings for your users, which you’ll read about in the next section, and you will install and configure the Remote Access role for the server in the first exercise.

Configuring PPP Options

You can use the PPP tab of the RRAS server’s Properties dialog box (see Figure 4.3) to control the PPP layer options available to clients that call in. The settings you specify here control whether the related PPP options are available to clients; you can use remote access policies to control whether individual connections can use them.

FIGURE 4.3 The PPP tab of the RRAS server’s Properties dialog box

This tab has four check boxes:

§ The Multilink Connections check box, which is selected by default, controls whether the server will allow clients to establish multilink connections when they call in.

§ The Dynamic Bandwidth Control Using BAP Or BACP check box determines whether clients and servers are allowed to add or remove links dynamically during a multilink session. If you enable this feature, you can throttle the amount of available bandwidth up or down on demand. It’s available only when the Multilink Connections check box is selected. (BAP stands for Bandwidth Allocation Protocol, and BACP stands for Bandwidth Allocation Control Protocol.)

§ The Link Control Protocol (LCP) is used to establish a PPP link and negotiate its settings. A variety of LCP extensions are defined in various RFCs; these extensions allow a client and server to agree dynamically about which protocols are being passed back and forth, among other things. The Link Control Protocol (LCP) Extensions check box controls whether these extensions are available. Windows 9x, NT, 2000, Vista, XP, Windows 7, and Windows 8 clients depend on the LCP extensions, so you should leave this check box selected.

§ The Software Compression check box controls whether RRAS will allow a remote client to use the Compression Control Protocol (CCP) to compress PPP traffic. In some cases, hardware compression at the modem level is more efficient, but not everyone has a compression-capable modem. You should leave this check box selected as well.

Configuring IP-Based Connections

TCP/IP is far and away the most commonly used remote access protocol; coincidentally, it’s also the most configurable of the protocols that Windows Server 2012 R2 supports. Both of these facts are reflected in the IPv4 and IPv6 tabs of the server’s Properties dialog box. Figure 4.4 shows the IPv4 tab.

FIGURE 4.4 The IPv4 tab of the RRAS server’s Properties dialog box

The controls on the IPv4 tab do the following:

§ The Enable IPv4 Forwarding check box controls whether RRAS will route IPv4 packets between the remote client and other interfaces on your RRAS server. When this box is checked, as it is by default, remote clients’ packets can go to the RRAS server or to any other host to which the RRAS server has a route. To allow clients to access resources on the RRAS server only, uncheck this box.

§ The IP Address Assignment control group lets you specify how you want remote clients to get their IP addresses. The default settings here depend on what you told the RRAS Setup Wizard during setup:

§ If you want to use a DHCP server on your network as the source of IP addresses for remote clients, select the Dynamic Host Configuration Protocol (DHCP) radio button and make sure that you have the DHCP relay agent installed and running.

§ If you’d rather use static address allocation, select the Static Address Pool radio button. Then, in the list below, specify which IP address ranges you want issued to clients.

§ The Enable Broadcast Name Resolution option allows remote clients to resolve TCP/IP names without the use of a WINS or DNS server. This feature is enabled by default, and it is new for Windows Server 2012.

Figure 4.5 shows the IPv6 tab of the RRAS server’s Properties dialog box.

FIGURE 4.5 The IPv6 tab of the RRAS Server’s Properties dialog box

The controls on the IPv6 tab do the following:

§ The Enable IPv6 Forwarding check box controls whether RRAS will route IPv6 packets between the remote client and other interfaces on your RRAS server. When this box is checked, as it is by default, remote clients’ packets can go to the RRAS server or to any other host to which the RRAS server has a route. To allow clients to access resources on the RRAS server only, uncheck this box.

§ The Enable Default Route Advertisement check box (enabled by default) makes the Border Gateway Protocol (BGP) routing protocol available. BGP can exchange routing information between Windows Server 2012 R2 routers. When this box is checked, your Windows Server 2012 R2 router can announce its route to other routers.

§ On the IPv6 tab, you can also set up your IPv6 prefix assignment.

In Exercise 4.1, I will show you how to install and configure the Remote Access role onto your server. Just like many of our installations, you will use Server Manager to install the Remote Access role. This role also installs the DirectAccess role onto your server.

EXERCISE 4.1: Installing the Remote Access Role

1. Open Server Manager.

2. On the Server Manager dashboard, click the Add Roles And Features link (number 2).

3. If a Before You Begin screen appears, click Next.

4. On the Selection type page, choose a role-based or feature-based installation and click Next.

5. Click the top radio button, Select A Server From The Server Pool, and choose the server in the Server Pool section. Click Next.

6. On the Select Server Roles screen, click the Remote Access check box. If a pop-up window appears telling you that you need to add features, click the Add Features button. Click Next.

7. On the Add Features page, click Next.

8. On the Remote Access page, click Next.

9. On the Select role services page, choose the first two check boxes: DirectAccess and VPN (RAS) and Routing. If a pop-up window appears telling you that you need to add additional features, click the Add Features button. Click Next.

10.At the Web Server Role (IIS) page, click Next.

11.At the Select Role Services page, click Next.

12.At the Confirmation screen, click the Install button.

13.Open the Routing and Remote Access MMC in Administrative Tools.

14.Right-click your server name and choose Configure And Enable Routing And Remote Access.

15.At the Welcome Screen, click Next.

16.Choose the Custom Configuration radio button. Click Next.

17.Choose VPN access. Click Next.

18.Click Finish at the Completing screen.

19.Click the Start Service button.

Understanding a VPN

Conventional dial-up access works well, but as you saw earlier, it can be expensive to implement, painful to manage, and extremely slow by today’s standards. VPNs offer a way around these problems by providing low initial and ongoing costs, easy management, and excellent speeds (depending on your connection). Windows Server 2012’s RRAS component includes two complete VPN implementations: one using Microsoft’s PPTP and one using a combination of the Internet-standard IPsec protocol and L2TP or SSTP.

The basic process of setting up a VPN is simple, but you need to think some things through before plunging ahead. Getting the VPN installation right may require small hardware or networking changes plus proper configuration of the VPN service. You will look at this process in the following sections.

How VPN Works

A VPN sits between your internal network and the Internet, accepting connections from clients in the outside world. In Figure 4.6, clients 1 and 2 are using different ISPs (probably because they’re at different physical locations). For example, a packet from client 1 goes from its computer to its ISP and then through some route, unknown to you, that eventually delivers it to the VPN server, which transforms it into a packet suitable for use on the internal network.

FIGURE 4.6 VPNs provide private connections between clients and servers across the Internet

Imagine a line around the internal network, and think of it as a security boundary. In general, you’ll want your VPN server to be outside any firewalls or network security measures that you have in place. The most common configuration is to use two NICs: one connects to the Internet, and the other connects either to the private network or to an intermediate network that itself connects to the private network. Of course, you can use any type of Internet connection you want for the VPN server, such as cable modem, DSL, T1, satellite, or whatever.

The point behind giving the VPN its own network adapter is that your VPN clients need a public IP address to which they can connect, and you probably don’t want them calling directly into your internal network. That also means that things will be easiest for your VPN users if the IP address for your VPN server’s external interface is statically assigned so that it won’t be changing on them when they least expect it.

Enabling RRAS as a VPN

If you’re already using RRAS for IP routing or remote access, you can enable it as a VPN server without reinstalling.

The General tab of the server’s Properties dialog box allows you to specify whether your RRAS server is a router, a remote access server, or both. The first step in converting your existing RRAS server to handle VPN traffic is to make sure that the IPv4 Remote Access Server or IPv6 Remote Access Server check box is selected on this tab.

Making this change requires you to stop and restart the RRAS service, but that’s OK because the snap-in will do it for you. Then you must configure VPN ports, as shown in the following sections.

Configuring a VPN

VPN configuration is extremely simple, at least for PPTP. Either a server can accept VPN calls or it can’t. If it can, it will have a certain number of VPN ports, all of which are configured identically. You don’t have to change or tweak much to get a VPN server set up, but you can adjust a few things as you like.

Configuring VPN Ports

The biggest opportunity to configure your VPN server is to adjust the number and kind of VPN ports available for clients to use. You can enable or disable either PPTP or L2TP, depending on what you want your remote users to be able to access. You accomplish this through the Ports Properties dialog box.

For conventional remote access servers, this dialog box shows you a list of hardware ports, but for servers that support VPN connections, there are two WAN Miniport device selections: one for PPTP and one for L2TP. (These aren’t really devices; they’re actually virtual ports maintained by RRAS for accepting VPN connections.) You configure these ports by selecting one and clicking the Configure button, which displays the Configure Device – WAN Miniport (PPTP) dialog box (see Figure 4.7).

FIGURE 4.7 The Configure Device – WAN Miniport (PPTP) dialog box

Three controls are pertinent to a VPN configuration:

§ The Remote Access Connections (Inbound Only) check box must be activated in order to accept VPN connections with this port type. To disable a VPN type (for instance, if you want to turn off L2TP), uncheck this box.

§ The Demand-Dial Routing Connections (Inbound And Outbound) check box controls whether this VPN type can be used for demand-dial connections. By default, this box is checked; you’ll need to uncheck it if you don’t want to use VPN connections to link your network with other networks.

§ The Maximum Ports control lets you set the number of inbound connections that this port type will support. By default, you get 5 PPTP and 5 L2TP ports when you install RRAS; you can use from 0 to 250 ports of each type by adjusting the number here.

You can also use the Phone Number For This Device field to enter the IP address of the public interface to which VPN clients connect. You might want to do this if your remote access policies accept or reject connections based on the number called by the client. Because you can assign multiple IP addresses to a single adapter, you can control VPN traffic by throttling which clients can connect to which addresses through a policy.

Troubleshooting VPNs

The two primary problems you might encounter with VPN are as follows:

§ Inability to establish a connection at all

§ Inability to reach some needed resource once connected

There’s a lot of common ground between the process of troubleshooting a VPN connection and the process of troubleshooting an ordinary remote access connection.

The following are some extremely simple—but sometimes overlooked—things to check when your VPN clients can’t connect. First, make sure your clients can make the underlying connection to their ISP; then, check the following:

§ Is RRAS installed and configured on the server?

§ Is the server configured to allow remote access? Check the General tab of the server’s Properties dialog box.

§ Is the server configured to allow VPN traffic? Check the Ports Properties dialog box to make sure that the appropriate VPN protocol is enabled and that the number of ports for that protocol is greater than 0.

§ Are there any available VPN ports? If you have 10 L2TP ports allocated, the 11th caller will not be able to connect.

§ Do the client and server match?

§ Is the VPN protocol used by the client enabled on the server? Windows 2000 and newer clients will try L2TP first and switch to PPTP as a second choice. However, clients on other OSs (including Windows NT) can normally expect L2TP, PPTP, or SSTP (2008 or higher).

§ Are the client and server authenticated correctly?

§ Are the username and password correct?

§ Does the user account in question have remote access permissions, either directly on the account or through a policy?

§ Do the authentication settings in the server’s policies (if any) match the supported set of authentication protocols?

If you check all of the simple stuff and find nothing wrong, it’s time to move on to checking more complex issues. These tend to affect more than one user, as opposed to the simple (and generally user-specific) issues just outlined. The problems include the following:

Policy Problems If you’re using a native-mode Windows Server 2012 R2 domain and you’re using policies, those policies may cause some subtle problems that show up under some circumstances:

§ Are there any policies whose Allow or Deny settings conflict with each other? Remember that all conditions of all policies must match to gain user access; if any condition of any policy fails or if there are any policies that deny access, the connection will be denied.

§ Does the user match all of the necessary conditions that are in place, such as time and date?

Network Problems If you’re using dynamic IP addressing, are there any addresses left in the pool? If the VPN server can’t assign an address, it won’t accept the connection.

Domain Problems Windows Server 2012 R2 RRAS servers can coexist with Windows NT RRAS servers, and both of them can interoperate with RADIUS servers from Microsoft and other vendors. Sometimes, though, this interoperation doesn’t work exactly as you’d expect. Here are some questions to ask:

§ Is the RRAS server’s domain membership correct? Your RRAS servers don’t have to be domain members unless you want to use native-mode features such as remote access policies.

§ If you’re in a domain, are the server’s group memberships correct? The server account must be a member of the RAS group and Internet Authentication Servers security group.

Managing Your Remote Access Server

RRAS server management is generally pretty easy because, in most cases, there’s not much to manage. You set up the server, and it answers calls. You’ll probably find it necessary to monitor the server’s ongoing activity, however, and you may find it necessary to log activity for accounting or security purposes.

You can monitor your server’s activity in a number of ways, including having the server keep local copies of its logs or having it send logging data to a remote RADIUS server. In addition, you can monitor the current status of any of the ports on your system.

Microsoft’s documentation distinguishes between event logging, which records significant things that happen such as the RRAS service starting up and shutting down, and authentication and accounting logging, which tracks things like when a user logged on and logged off. The settings for both types of logging are intermingled in the RRAS snap-in.

Managing Remote Users with a RADIUS Server

Remote Authentication Dial-In User Service (RADIUS) allows for maintaining and managing your remote users. A RADIUS server allows Remote Access Service (RAS) clients and dial-up routers to be authenticated.

Network Policy Server (NPS) is Microsoft’s implementation of a RADIUS server in Windows Server 2012. NPS is replacing Windows Server 2003 Internet Authentication Service (IAS). NPS, working as a RADIUS server, allows for authentication, authorization, and accounting for wireless and VPN networks.

NPS allows a server to perform the duties of a RADIUS proxy. A RADIUS proxy allows the routing of RADIUS messages between RADIUS clients (RAS) and RADIUS servers. NPS also gives you the ability to record information about forwarded messages in an accounting log.

Monitoring Overall Activity

The Server Status node in the RRAS snap-in shows you a summary of all the RRAS servers known to the system. When you select the Server Status item, the right pane of the MMC will list each known RRAS server. Each entry in the list tells you whether the server is up, what kind of server it is, how many ports it has, how many ports are currently in use, and how long the server has been up. You can right-click any Windows Server 2012 R2 RRAS server in this view to start, stop, restart, pause, or resume its RRAS service; disable RRAS on the server; or remove the server’s advertisement from Active Directory (provided, of course, that you’re using Active Directory).

Controlling Remote Access Logging

A standard RRAS installation will always log some data locally, but that’s pretty useless unless you know what gets logged and where it goes. Each RRAS server on your network has its own set of logs, which you manage through the Remote Access Logging folder. Within that folder, you’ll usually see a single item labeled Local File, which is the log file stored on that particular server.

If you don’t have Windows accounting or Windows authentication turned on, you won’t have a local log file. Depending on whether you’re using RADIUS accounting and logging, you may see additional entries.

Setting Server Logging Properties

You can control server logging at the server level. You use the Logging tab to control what level of detail you want in the server’s event log.

These controls regulate all logging by RRAS, not just remote access log entries.

You have four choices for the level of logged detail:

§ The Log Errors Only radio button instructs the server to log errors and nothing else. This gives you an adequate indication of problems after they happen, but it doesn’t point out potential problems noted by warning messages.

§ The Log Errors And Warnings radio button is the default choice. This forces the server to log error and warning messages to the event log, giving you a nice balance between information content and log volume.

§ The Log All Events radio button causes the RRAS service to log mass quantities of messages, literally covering everything the server does. Although this voluminous output is useful for troubleshooting (or even for getting a better understanding of how remote access works), it’s overkill for everyday use.

§ The Do Not Log Any Events radio button turns off all event logging for RRAS.

Don’t use the Do Not Log Any Events option. The service’s logs are important in case of a problem.

The Log Additional Routing And Remote Access Information check box allows you to turn on the logging of all PPP negotiations and connections. This can provide valuable information when you’re trying to figure out what’s wrong, but it adds a lot of unnecessary bulk to your log files. Don’t turn it on unless you’re trying to pin down a problem.

Setting Log File Properties

By selecting an individual log file in the snap-in, you can change what events will be logged in that file. The Local Log File Properties dialog box has two tabs:

§ The Settings tab controls what gets logged in the file:

§ Accounting Requests governs whether events related to the service will be logged (as well as accounting data). You should always leave this checked.

§ Authentication Requests adjusts whether successful and failed logon requests are logged. You should always leave this checked.

§ Periodic Status controls whether interim accounting packets are permanently stored on disk. You should usually leave this checked.

§ Periodic Authentication Requests adjusts whether successful and failed logon requests are periodically logged. You should always leave this checked.

§ The Log File tab (see Figure 4.8) controls the format of the file, specifically, how the log file is written to disk. You use this tab to designate three things:

FIGURE 4.8 The Log File tab

§ The Directory field shows where the log file is stored. By default, each server logs its data in systemroot\system32\LogFiles. You can change this location to wherever you want.

§ The Format controls determine the format of the log file. By default, Windows Server 2000, 2003, 2008/2008 R2, and 2012/2012 R2 use the database-compatible file format. This format makes it easy for you to take log data and store it in a database, enabling more sophisticated postprocessing for things such as billing and chargebacks.

§ The Create A New Log File controls determine how often new log files are created. For example, some administrators prefer to start a new log file each week or each month, whereas others are content to let the log file grow without end. You can choose to have RRAS start new log files every day, week, month, never, or when the log file reaches a certain size.

Having correct accounting and authorization data is critical to maintaining a good level of security. Exercise 4.2 walks you through configuring remote access logging.

EXERCISE 4.2: Changing Remote Access Logging Settings

1. Open the RRAS MMC snap-in by pressing the Windows key and selecting Administrative Tools ⇒ Routing And Remote Access.

2. Navigate to the Remote Access Logging and Policies folder. Right-click the folder and select Launch NPS.

3. On the left pane, click Accounting. On the right side, click Change Log File Properties.

4. The Local File Logging dialog box appears. On the Settings tab, make sure that all check boxes are marked.

5. Switch to the Log File tab, and in the Create A New Log File controls, select the When Log File Reaches This Size option. Enter 50 to set the maximum size of the log file to 50MB.

6. Click the OK button. Close the Network Policy Server window.

Reviewing the Remote Access Event Log

You use the Log File tab to specify the format, size, and location of the log file. Once you have a log file, however, what do you do with the log information? Windows Server 2012 R2 online help has an exhaustive list of all of the fields logged for each connection attempt and accounting record. Because of the availability of online help, you don’t need to have all of those fields memorized, and you don’t have to remember exactly how to make sense of the log entries.

Why bother reviewing the logs? One nice feature is that each entry in the authentication log indicates which remote access policy was applied (either to accept or to reject the connection). This is a good way to identify problems with policies because sometimes multiple policies can combine to have an effect that you didn’t expect.

Furthermore, if it’s desirable in your environment, you can use the logged data to generate accounting reports to tell you things such as the average utilization of your dial-in ports, the top 10 users of dial-in connect time, or how much online time accounts or certain Windows groups use.

Monitoring Ports and Port Activity

You can monitor port status and activity from the RRAS snap-in. The Ports folder under the server contains one entry for each defined port. When you select the Ports folder, you’ll see a list of the ports and their current status. The list indicates whether each port is a dial-in or VPN port and whether it’s active, so you can get a quick summary of your server’s workload at any time.

Double-clicking an individual port displays the Port Status dialog box (see Figure 4.9). This dialog box shows information such as a port’s line speed (Line BPS), the amount of transmitted and received data (Bytes In and Bytes Out), and the network address for each protocol being carried on the port. This is a useful tool for verifying whether a port is in active use, and it gives you a count of the number of transmission and reception errors on the port.

FIGURE 4.9 The Port Status dialog box

Network Address Translation

Network Address Translation (NAT) provides an advantage with routing and tunneling. NAT (also referred to as network masquerading) allows a router to translate one IP address to another across the tunnel. This allows you to use private IP addressing internally but use pubic addresses between the tunnels.

The huge advantage of NAT is the ability for you to share a single public IP address and single Internet connection between multiple locations using private IP addressing schemes. The nodes on the private network use nonroutable private addresses. NAT maps the private addresses to the public address.

Implementing NAT

Implementing NAT is an easy process. I am going to show you the steps needed to implement NAT, but I am not going to do it as an exercise. To set up NAT in an exercise without a tunnel or without multiple networks is not always an easy thing to do. So, I will just show you how to implement NAT in case you need to do it at work. To run these steps, you must be a member of at least the local Administrators group or higher. The following steps show you how to implement NAT:

1. Start the Routing and Remote Access MMC snap-in (under Administrative Tools). Right-click your server name and choose Configure And Enable Routing And Remote Access.

2. At the Welcome Screen, click Next.

3. Choose the Custom Configuration radio button. Click Next.

4. Click NAT and click Next.

5. Start Service.

6. Expand your server name.

7. Expand IPv4.

At this point, you can configure NAT. If you need to install NAT, you must have a system with multiple NIC devices or a demand-dial setup.

NAT is also commonly used for Internet connections, but this is done through your firewall or router. For example, let’s say you have an Internet service provider that issues you only four valid Internet TCP/IP addresses for you to use on your network. You can set up NAT and program it to use those four valid addresses. Then, when a user from the network wants to access the Internet, NAT swaps the user’s internal IP address for one of the valid IP addresses.

Configuring a VPN Client

Dial-up RAS clients and VPN clients are similar. Almost all of the options that are available when you set up a RAS client are also available when you set up a VPN client. The main differences are as follows:

§ VPN clients specify the server’s IP address, whereas RAS clients specify the server’s phone number.

§ VPN clients require an underlying connection to the Internet.

Client configuration is not a focus of the exam, so in this chapter you will learn how to configure a VPN client but not a RAS client. Just remember that the RAS client configuration is extremely similar and that RAS clients are slowly fading away. Thus, here I will focus on VPN settings only.

VPN connections are almost always created on client workstations, so this section describes the settings in Windows 7 and Windows 8.

When you establish a virtual private network connection, you’re actually building an encrypted tunnel between you and some other machine. The tunneled data is carried over an insecure network, such as the Internet.

Once you’ve created a connection, you can change its properties at any time by opening its Properties dialog box. The Dial-Up Connection Properties dialog box has a total of five tabs that you can use to adjust all of the pertinent settings for each connection.

Don’t confuse these settings with the ones in the Local Area Connection Properties dialog box; they serve entirely different purposes.

The General Tab

The General tab of the Connection Properties dialog box (the box is called Dial-Up Connections or VPN Connections, depending on whether you’re configuring dial-up RAS or VPN) is where you specify either the IP address of the VPN server or the modem and phone number to use with this particular connection. Some fields have been filled in already from when you used the Network Connection Wizard. Figure 4.10 shows the VPN settings.

FIGURE 4.10 General tab of the VPN Connection Properties dialog box

The General tab has a field where you enter the VPN server address or hostname. The First Connect group lets you specify which dial-up connection, if any, you want brought up before the VPN connection is established.

With the General tab, you can also do the following:

§ Set VPN options:

§ Enter the VPN server address or hostname.

§ Specify whether to dial another connection automatically first and then specify the connection to dial.

§ Set RAS options:

§ Change the modem this connection uses, or the settings for the modem you already have, with the Configure button.

When configuring dial-up, you can also use the Phone And Modem Options control panel to adjust a broader range of modem settings.

The Options Tab

The Options tab holds settings that control how DUN dials and redials the connection. The controls in this dialog box are segregated into two groups. The Dialing Options group holds controls that govern DUN’s interface behavior while dialing, and the Redialing Options group controls whether and how DUN will redial if it doesn’t immediately connect (see Figure 4.11).

FIGURE 4.11 Options tab of the VPN Connection Properties dialog box

Dialing Options

Four dialing options are available in the Dialing Options group:

§ The Display Progress While Connecting check box (selected by default) instructs DUN to keep you updated on its progress as it attempts to raise the connection.

§ The Prompt For Name And Password, Certificate, Etc. check box is also selected by default. When it’s on, Windows will prompt you for any credentials it needs to authenticate your connection to the remote server. This may be a username, a password, a public key certificate, or some combination of the three, depending on what the remote end requires.

§ The Include Windows Logon Domain check box is unchecked by default. It forces DUN to include the domain name of the domain to which you’re logged on as part of the authentication credential. Leave this unchecked unless you’re dialing into a Windows NT/2000 network that has a trust relationship with your logon domain.

§ For RAS connections, a Prompt For Phone Number check box tells DUN to display the phone number in the connection dialog box. This box is checked by default. This gives you a chance to edit the phone number before dialing; you may want to uncheck it if you (or your users) are prone to making accidental changes.

Redialing Options

The settings in the Redialing Options group control how DUN will attempt to redial the specified number if the remote end is busy or doesn’t answer with a recognizable carrier tone. These settings are as follows:

§ The Redial Attempts field controls how many attempts DUN will make to raise the other end before giving up. The default value is 3, but you can set any value from 0 (meaning that DUN won’t attempt to redial) to 999,999,999.

§ The Time Between Redial Attempts drop-down menu controls how long DUN will wait after each failed call before it tries again. Values in the drop-down menu range from 1 second all the way up to 10 minutes, with various increments in between.

§ The Idle Time Before Hanging Up drop-down menu lets you specify an inactivity timer. If your connection is idle for longer than the specified period, your client will terminate the call. Note that the remote end may drop the call sooner than your client, depending on how it’s configured. By default, this drop-down menu is set to Never, meaning that your client will never drop a call. If you want an inactivity timer, you can pick values ranging from 1 minute to 24 hours.

§ The Redial If Line Is Dropped check box automatically redials the number if you are disconnected.

The Security Tab

How useful you find the Security tab will depend on whom you’re calling. The default settings it provides will work fine with most Internet service providers and corporate dial-up facilities, but Windows 7 and Windows 8 have a broad range of security settings that you can change if you require. The Security Options group contains controls that directly affect the security of your connection. The Advanced (Custom Settings) radio button controls settings such as encryption and authentication protocols.

Security Options

The controls in the Security Options group are pretty straightforward. The security settings in effect for this connection are governed by your choice between the Typical (Recommended Settings) and Advanced (Custom Settings) radio buttons (see Figure 4.12).

FIGURE 4.12 Security tab of the VPN Connection Properties dialog box

Typical (Recommended Settings)

Usually, it’s best to stick with the Typical (Recommended Settings) option and use its subordinate controls to pick a canned setting that matches your needs. These subordinate controls are as follows:

§ The Validate My Identity As Follows drop-down menu lets you choose among the following authentication methods:

§ Unsecured passwords (the default, and the only type of authentication that most networks support)

§ Secured passwords

§ Smart card authentication (useful only when calling another Windows 2000, 2003, 2008/2008 R2, or 2012/2012 R2 network)

§ If you choose to require a secured password, the Automatically Use My Windows Logon Name And Password (And Domain If Any) check box instructs DUN to offer to the remote end the logon credentials you used to log on to the computer or domain. This is useful only if you’re dialing into a network that has access to your domain authentication information.

§ If you require a secured password or smart card authentication, the Require Encryption (Disconnect If None) check box allows you to have either an encrypted connection or none at all. If you check this box, your client and the remote server will attempt to negotiate a common encryption method. If they can’t (perhaps because the remote end doesn’t offer encryption), your client will hang up.

Advanced (Custom Settings)

If you select the Advanced (Custom Settings) radio button and then click the Settings button, you’ll see the Advanced Security Settings dialog box. Its controls are more complex than the ones on the Security tab.

The first field is the Data Encryption drop-down menu. Windows 8 offers you the opportunity to encrypt both sides of network connections using IPsec. This capability extends to dial-up connections too. The drop-down menu gives you the following four choices:

§ No Encryption Allowed means that the server will drop your call if it requires encryption because you can’t provide it.

§ Optional Encryption tells the client to request encryption but to continue the call if it’s not available.

§ Require Encryption tells the client to request encryption and to refuse to communicate with servers that don’t support it.

§ Maximum Strength Encryption tells the client to communicate only with servers that offer the same strength encryption it does. For example, with this setting in force, a North American Windows Server 2008 R2 machine running 3DES won’t communicate with a French Windows XP machine because the French machine uses the weaker exportable encryption routines.

The Authentication section controls which authentication protocols this client can use. The default setting, Use Extensible Authentication Protocol (EAP), is for standard Windows authentication (using the MD5-Challenge method) or certificate-based authentication (using the Smart Card Or Other Certificate choice in the drop-down menu).

The Allow These Protocols radio button is followed by a long list of authentication protocols. Although the specifics of how they work are different, the basic idea behind all of these protocols is the same. Each provides a secure way for a client to prove its identity to a server. By selecting the appropriate check boxes, you can make your client use the same protocols as the remote end.

The Networking Tab

You use the Networking tab (see Figure 4.13) to control which protocols your client will attempt to use when communicating with other servers.

FIGURE 4.13 Networking tab of the VPN Connection Properties dialog box

The list box in the middle of the tab shows the network protocols installed on the client. Protocols marked with a check are available for use with this connection. Usually, when configuring RAS, you’ll see TCP/IP and Client For Microsoft Networks marked, which indicates that those two protocols can be used over the connection.

The Install, Uninstall, and Properties buttons work just as they do in the Local Area Connection Properties dialog box. By using them, you can control which protocols are on your machine and their settings.

It’s worth mentioning that selecting Internet Protocol (TCP/IP) in the protocols list and opening its Properties dialog box gives you access to a set of properties that are completely distinct from any TCP/IP settings that may apply to your LAN interfaces. Usually, the dial-up TCP/IP settings are configured to obtain an IP address and DNS information from the remote server, although if you need to, you can override these settings.

The Sharing Tab

Internet Connection Sharing allows other users to connect to the Internet through this machine. The machine on which you enable this feature works like a gateway to the Internet (see Figure 4.14).

FIGURE 4.14 Sharing tab of the VPN Connection Properties dialog box

Configuring a Web Application Proxy

One of the new advantages of using the Remote Access role service in Windows Server 2012 R2 is the Web Application Proxy. Normally, your users access applications on the Internet from your corporate network. The Web Application Proxy reverses this feature, and it allows your corporate users to access applications from any device outside the network.

Administrators can choose which applications to provide reverse proxy features, and this allows administrators the ability to give access selectively to corporate users for the desired application that you want to set up for the Web Application Proxy service.

The Web Application Proxy feature allows applications running on servers inside the corporate network to be accessed by any device outside the corporate network. The process of allowing an application to be available to users outside of the corporate network is known as publishing.

Publishing Applications

One disadvantage to corporate networks are that the machines that access the network are normally devices issued by the organization. That’s where Web Application Proxy publishing can help.

Web Application Proxy allows an administrator to publish an organization’s applications, thus allowing corporate end users the ability to access the applications from their own devices. This is becoming a big trend in the computer industry called bring your own device (BYOD).

In today’s technology world, users are buying and using many of their own devices, even for business work. Because of this, the users are comfortable with their own devices. Web Application Proxy allows an organization to set up applications and enable their corporate users to use these applications with the devices the users already own including computers, tablets, and smartphones.

The client side is easy to use as long as the end user has a standard browser or Office client. End users can also use apps from the Microsoft Windows Store that allow the client system to connect to the Web Application Proxy.

Configuring Pass-Through Authentication

Now when setting up the Web Application Proxy so that your users can access applications, you must have some kind of security or everyone with a device would be able to access and use your applications.

Because of this, Active Directory Federation Services (AD FS) must always be deployed with Web Application Proxy. AD FS gives you features such as single sign-on (SSO). Single sign-on allows you to log in one time with a set of credentials and use that set of credentials to access the applications over and over.

Pass-through authentication is truly a great benefit for your end users. Think of having a network where a user has to log in every time that user wants to access an application. The more times you make your end users log into an application, the more chances there are that the end user will encounter possible issues. Pass-through authentication works in the following way:

1. The client enters a URL address on their device, and the client system attempts to access the published web application.

2. The Web Application Proxy sends the request to the proxy server.

3. If the backend server needs the user to authenticate, the end user needs to enter their credentials only once.

4. After the server authenticates the credentials, the client has access to the published web application.

When an administrators sets up applications to use pass-through pre-authentication, additional features of AD FS will not function. For example, you will not be able to use AD FS Workplace Join, multifactor authentication (MFA), and multifactor access control.

Understanding DirectAccess

DirectAccess was a new technology that was introduced in the Windows Server 2008 R2 and Windows 7 operating systems. DirectAccess has been improved upon, and it is also available for Windows 8 and Windows Server 2012 R2.

DirectAccess allows a remote user to work on their corporate network when they are away from the office without the need for a VPN. As long as the remote user is connected to the Internet, DirectAccess will automatically connect the remote user to the corporate network without the need for any user intervention.

When a user’s DirectAccess-enabled laptop is connected to the Internet, a bidirectional connection is automatically established with the user’s corporate network. Because the connection is bidirectional, the IT administrator can also remotely manage the Windows 7 or Windows 8 machine while the machine is away from the network.

DirectAccess vs. VPNs

There really is no debate between VPN or DirectAccess—DirectAccess is the better way to go. The downside to DirectAccess is that it requires a great deal of time, resources, and knowledge to set it up properly.

There are a few problems with using VPNs to connect to a network. One issue is that when a user gets disconnected from their VPN connection, they must reestablish the VPN connection.

Another issue with VPNs is that many organizations filter VPN connection traffic. It may not be possible for an organization to open a firewall to allow VPN traffic. Also, if your intranet and your Internet connections are the same as your VPN connections, this can cause your Internet to be slower.

DirectAccess does not face the same limitations of a VPN. DirectAccess allows a laptop or desktop that is configured properly to connect automatically using a bidirectional connection between the client and the server.

To establish this connection, DirectAccess uses Internet Protocol Security (IPsec) and IPv6. IPsec provides a high level of security between the client and the server, and IPv6 is the protocol that the machines use.

Understanding the DirectAccess Process

Before you can set up the features and benefits of DirectAccess, there are some prerequisites that I must first go over. DirectAccess is great way to get your users to access the network from the road, but it is not the easiest thing to set up, and it must be done correctly.

DirectAccess Prerequisites

As with any software package, role, or feature, when you install any one of these, there are always prerequisites that you must deal with. DirectAccess is no different. The following is a list of DirectAccess Server with Advanced Settings prerequisites:

§ A public key infrastructure must be deployed.

§ ISATAP in the corporate network is not supported. If you are using ISATAP, you should remove it and use native IPv6.

§ Computers that are running the following operating systems are supported as DirectAccess clients:

§ Windows Server 2012 R2

§ Windows 8.1 Enterprise

§ Windows Server 2012

§ Windows 8 Enterprise

§ Windows Server 2008 R2

§ Windows 7 Ultimate

§ Windows 7 Enterprise

§ Force tunnel configuration is not supported with KerbProxy authentication.

§ Changing policies by using a feature other than the DirectAccess management console or Windows PowerShell cmdlets is not supported.

§ Separating NAT64/DNS64 and IPHTTPS server roles on another server is not supported.

The following is the list of prerequisites if you want to manage DirectAccess clients remotely:

§ Windows Firewall must be enabled on all profiles.

§ ISATAP in the corporate network is not supported. If you are using ISATAP, you should remove it and use native IPv6.

§ Computers that are running the following operating systems are supported as DirectAccess clients:

§ Windows Server 2012 R2

§ Windows 8.1 Enterprise

§ Windows Server 2012

§ Windows 8 Enterprise

§ Windows Server 2008 R2

§ Windows 7 Ultimate

§ Windows 7 Enterprise

§ Changing policies by using a feature other than the DirectAccess management console or Windows PowerShell cmdlets is not supported.

Understanding DirectAccess

To understand DirectAccess better, it helps to understand the process involved with how DirectAccess operates. The following steps, taken from the Microsoft white papers, show how DirectAccess operates.

1. The Windows 8 DirectAccess client determines whether the machine is connected to a network or the Internet.

2. The Windows 8 DirectAccess computer tries to connect to the web server specified during the DirectAccess setup configuration.

3. The Windows 8 DirectAccess client computer connects to the Windows Server 2012 R2 DirectAccess server using IPv6 and IPsec. Because most users connect to the Internet using IPv4, the client establishes an IPv6-over-IPv4 tunnel using 6to4 or Teredo.

4. If an organization has a firewall that prevents the DirectAccess client computer using 6to4 or Teredo from connecting to the DirectAccess server, the Windows 8 client automatically attempts to connect using the IP-HTTPS protocol.

5. As part of establishing the IPsec session, the Windows 8 DirectAccess client and server authenticate each other using computer certificates for authentication.

6. The DirectAccess server uses Active Directory membership, and the DirectAccess server verifies that the computer and user are authorized to connect using DirectAccess.

7. The DirectAccess server begins forwarding traffic from the DirectAccess client to the intranet resources to which the user has been granted access.

Now that you understand how DirectAccess works, let’s look at the requirements for setting up DirectAccess on your network.

Knowing the DirectAccess Infrastructure Requirements

To set up DirectAccess, you must make sure that your network infrastructure meets some minimum requirements. The following are the requirements for setting up DirectAccess:

§ Windows Server 2012 R2 configured to use DirectAccess. The Windows Server 2012 R2 machine will be set up as a multihomed system. This means your server will need two network adapters so that one adapter is connected directly to the Internet and a second adapter is connected to the intranet. Each network adapter will be configured with its own TCP/IP address.

§ Windows 7 or Windows 8 client machines configured to use DirectAccess.

§ Minimum of one domain controller and one Domain Name System (DNS) server running Windows Server 2008 SP2, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.

§ Certificate authority (CA) server that will issue computer certificates, smart card certificates, or health certificates.

§ IPsec policies to specify protection for traffic.

§ IPv6 on the DirectAccess server that uses ISATAP, Teredo, or 6to4.

Summary

In this chapter, you learned how to install and configure Routing and Remote Access Services to handle dial-in connections, how to configure appropriate encryption and security settings so that communication between the client and server is encrypted and authenticated, how to install RRAS to provide VPN service using the PPTP and L2TP protocols, how to configure VPN services on the server and client, and, finally, how to troubleshoot common problems with VPNs.

Exam Essentials

Know how to install and configure RAS at the server level. The RAS installation process is driven by the Routing and Remote Access Server Setup Wizard, which you use to set up a dial-up server. You can specify whether the server acts as a remote access server, specify what authentication providers and settings you want the server to use, control the settings applied to each protocol you have installed, specify which PPP protocols (including multilink) the clients on this server are allowed to use, and control what level of log detail is kept for incoming connections.

Know how to install and configure a VPN server. If you don’t have RRAS installed, you’ll need to install it, activate it, and configure it as a VPN server. If you’re already using RRAS for IP routing or remote access, you can enable it as a VPN server without reinstalling. VPN configuration is extremely simple, at least for PPTP. Either a server can accept VPN calls or it can’t. If it can, it will have a certain number of VPN ports, all of which are configured identically.

Know how to configure an RRAS client. Most client connections are made on Windows 8, Windows 7, Windows Vista, or Windows XP Professional workstations. Dial-in and VPN connections are configured similarly, but when creating a VPN connection, you must substitute an IP address for a phone number.

Review Questions

1. You have a local DHCP server for your dial-in clients, but you also want to use the DHCP relay agent to forward requests to a remote DHCP server if the local server doesn’t answer a request. To do this, you must do which of the following?

A. Add a static route to the remote server.

B. Adjust the boot threshold on the DHCP relay agent interface for the remote network so that the local server has enough time to respond.

C. Adjust the DHCP Forwarding Time parameter in the registry.

D. Adjust the forwarding time in the DHCP Relay Agent Global Properties dialog box.

2. You are considering multilink PPP in order to increase bandwidth available for a dial-up client. Which of the following is not a benefit of multilink?

A. Multilink can make the client experience faster by combining multiple phone lines and creating one logical PPP connection.

B. Multilink enables the encryption of data between the client and the server.

C. Multilink can be relatively low in cost and can utilize existing infrastructure.

D. Multilink is easy to use and included in Windows Server 2012 R2 for both inbound and outbound calls.

3. Your company has offices in five locations around the country. Most of the users’ activity is local to their own network. Occasionally, some of the users in one location need to send confidential information to one of the other four locations or to retrieve information from one of them. The communication between the remote locations is sporadic and relatively infrequent, so you have configured RRAS to use demand-dial lines to set up the connections. Management’s only requirement is that any communication between the office locations be appropriately secured. Which of the following steps should you take to ensure compliance with this requirement? (Choose all that apply.)

A. Configure CHAP on all the RRAS servers.

B. Configure PAP on all the RRAS servers.

C. Configure MPPE on all the RRAS servers.

D. Configure L2TP on all the RRAS servers.

E. Configure MS-CHAPv2 on all the RRAS servers.

4. Your small financial consulting company has a stand-alone Windows 2012 R2 server that provides a central location for your home-based consultants to upload and download spreadsheet files using Windows 8. A few of the consultants still use Windows XP Professional workstations. You want to set up VPN connections between the consultants and the RRAS server. The RRAS server is connected to a small peer-to-peer network of five Windows XP Professional workstations that use the network for storing files, including the files that the consultants are uploading and downloading. What authentication protocol should you use for the VPN?

A. CHAP

B. MS-CHAPv2

C. EAP-TLS

D. PAP

5. You recently migrated your company’s Windows 2003 network to Windows Server 2012 R2. This migration includes 300 Windows 7 and Windows 8 workstations and 8 Windows Server 2012 R2 servers. Your company has just acquired another company with offices down the street. It has a Windows NT network that needs to be migrated to Windows Server 2012 R2 as well, and you have already begun to move the servers to the new operating system and associated services. Because you have a tight cap on expenses for network additions, you currently can’t afford leased lines between the buildings. Until you can get support for them, you are going to create a VPN that is both encrypted and authenticated between the two facilities over the Internet connections that already exist. What do you need to implement to achieve this goal? (Choose all that apply.)

A. L2TP

B. PPTP

C. IPsec

D. RADIUS

E. MS-CHAPv2

6. You have implemented VPNs to connect the various locations of your organization. These locations include offices in New York, Sacramento, Memphis, and Omaha, with a significant LAN in each one. The RRAS server is set up such that the users aren’t aware of the intricacies of the connections. You are beginning to have problems with the connections between the offices and, as a result, the number of support calls is growing dramatically. What configurations could you use to troubleshoot the communication problems?

A. L2TP using MPPE

B. L2TP unencrypted

C. L2TP using IPsec in transport mode

D. L2TP using IPsec in tunnel mode

7. Your company’s 450 sales reps are finally going to receive laptops so that they can communicate with the corporate office whenever they need information stored on the corporate network. The corporate network is fully upgraded to Windows Server 2012 R2, including the default configuration of the RRAS server for the remote connectivity over VPNs. You have installed Windows 8 with the default configuration on all of the laptops and have added the sales reps to a special group in Active Directory. After you test the laptops, everything appears to work fine. You ship them out and, as they reach the sales reps, you monitor their initial connections. During the next few days, you begin receiving support calls from people complaining they cannot connect to the network. What is the most likely cause of the problem?

A. The Windows 8 clients are not configured to support a VPN.

B. The default RRAS configuration does not support VPNs.

C. The default RRAS configuration does not support enough VPN connections.

D. The default RRAS configuration does not support L2TP.

E. The Windows 8 client default configuration does not support L2TP.

8. You are the network administrator for a company with two offices; one is located on the East Coast and the other is located on the West Coast. Sales information needs to be sent from the East Coast to the West Coast office on a regular basis, and some payroll information and accounting reports need to be sent back to the East Coast. The owner of your company has been reading stories in the press about security problems on the Internet and refuses to allow any company information to travel through the Internet, regardless of how much you talk about securing those transmissions. The communications between the sites occur approximately once a week. What steps would you take to ensure secure authentication and secure transmission while not spending too much money? (Choose all that apply.)

A. Configure PAP as the authentication method between the servers.

B. Install RRAS on a server at each location and keep the line open with an ISDN connection that will always be available for the communication.

C. Install RRAS on a server at each location and configure demand-dial to open the connection each time the transmission occurs.

D. Configure CHAP as the authentication method between the servers.

E. Configure MS-CHAPv2 as the authentication method between the servers.

F. Configure IPsec as the encryption method between the servers.

G. Configure MPPE as the encryption method between the servers.

H. Configure L2TP as the encryption method between the servers.

9. You are using an RRAS server to manage remote access to your small Windows Server 2012 R2 network that serves a single location. RRAS provides access to several remote users and to the people who have machines on the local network but occasionally want to access the network from home or from hotels when on the road. Regardless of the category of user, everyone is authenticated through Active Directory. You haven’t spent much time reviewing the use of this remote connectivity since you configured the system, but now there is a concern about unauthorized users as well as intermittent problems that remote users are experiencing when connecting to the network. You’ve been asked to prepare a report for management describing the extent of these problems in the company. You recall that when you set up the system, you configured the logging to track all connection attempts using local Windows accounting. Where will you find the logging information that you need for preparing your report?

A. The Performance Monitor log

B. Active Directory

C. The systemroot\System32\LogFiles folder

D. The system event log

E. The RRAS authentication log

10. Your area of responsibility at the All-Terrain Vehicle Rentals Company is to build, deploy, and maintain the remote access system for the Windows Server 2012 R2 network. The system consists of four RRAS servers that serve 200 users across the country. The users often travel from location to location, and they access different servers depending on where they call in. You put together a management station to monitor all of the RRAS servers so that you can keep an eye on this critical aspect of your network. What tool do you use to accomplish this?

A. The Server Monitor of the RRAS snap-in

B. The Server Status node of the RRAS snap-in

C. The System Monitor snap-in

D. The MMC