Now that we have some general ideas about how we want to implement our remote access technologies, where do we begin? Most services that you want to run on a Windows Server begin with a role installation, but the implementation of remote access begins before that. Let's walk through the process of taking a new server and turning it into a Microsoft Remote Access server.
All of our work will be accomplished on a new Windows Server 2016. We are taking the two-NIC approach to networking, and so we have two NICs installed on this server. The Internal NIC is plugged into the corporate network and the External NIC is plugged into the Internet for the sake of simplicity. The External NIC could just as well be plugged into a DMZ.
Follow these steps to turn your new server into a Remote Access server:
- Assign IP addresses to your server. Since this is a multi-homed system with both internal and external networks connected, make sure you follow the steps in the Multi-homing your Windows Server 2016 recipe in Chapter 3, Security and Networking. Remember, the most important part is making sure that the Default Gateway goes on the External NIC only.
- Join the new server to your domain.
- Install an SSL certificate onto your DirectAccess server, which you plan to use for the IP-HTTPS listener. This is typically a certificate purchased from a public CA.
- If you're planning to use client certificates for authentication, make sure to pull down a copy of the certificate from your internal CA to your DirectAccess server.
Tip
You want to make sure certificates are in place before you start the configuration of DirectAccess. This way the wizards will be able to automatically pull in information about those certificates in the first run. If you don't, DA will set itself up to use self-signed certificates, which are a security no-no.
- Use Server Manager to install the Remote Access role. You should only do this after completing the previous steps.
- If you plan to load balance multiple DirectAccess servers together at a later time, make sure to also install the feature called Network Load Balancing.
- After selecting your role and feature, you will be asked which Remote Access role services you want to install. For our purposes of getting the remote workforce connected back into the corporate network, we want to choose DirectAccess and VPN (RAS).
- Now that the role has been successfully installed, you will see a yellow exclamation mark notification near the top of Server Manager indicating that you have some Post-deployment Configuration that needs to be done.
- Unfortunately, Server Manager leads you to believe that launching the Getting Started Wizard (GSW) is the logical next step. However, using the GSW as the mechanism for configuring your DirectAccess settings is kind of like roasting a marshmallow with a pair of tweezers. In order to ensure you have the full range of options available to you as you configure your remote access settings and that you don't get burned later, make sure to launch the configuration this way:
- Click on the Tools menu from inside Server Manager and launch the Remote Access Management Console.
- In the left window pane, navigate to Configuration | DirectAccess and VPN.
- Click on the second link, the one that says Run the Remote Access Setup Wizard. Please note that once again the top option is to run that pesky Getting Started Wizard. Don't do it! I'll explain why in the How it works... section of this recipe.
- Now you have a choice that you will have to answer for yourself. Are you configuring only DirectAccess, only VPN, or a combination of the two? Simply click on the option that you want to deploy. Following your choice, you will see a series of steps (Steps 1 through 4) that need to be accomplished. This series of mini-wizards will guide you through the remainder of the DirectAccess and VPN particulars. This recipe isn't large enough to cover every specific option included in those wizards, but at least you now know the correct way to bring a DA/VPN server into operation.
The remote access technologies included in Server 2016 have great functionality, but their initial configuration can be confusing. Following the procedure listed in this recipe will set you on the right path to be successful in your deployment, and prevent you from running into issues down the road. The reasons that I absolutely recommend you stay away from using the shortcut deployment method provided by the Getting Started Wizard are twofold:
- GSW skips a lot of options as it sets up DirectAccess, so you don't really have any understanding of how it works after finishing. You may have DA up-and-running, but have no idea how it's authenticating or working under the hood. This holds so much potential for problems later, should anything suddenly stop working.
- GSW employs a number of bad security practices in order to save time and effort in the setup process. For example, using the GSW usually means that your DirectAccess server will be authenticating users without client certificates, which is not a best practice. Also, it will co-host something called the NLS website on itself, which is also not a best practice. Those who utilize the GSW to configure DirectAccess will find that their GPO, which contains the client connectivity settings, will be security-filtered to the Domain Computers group. Even though it also contains a WMI filter that is supposed to limit that policy application to only mobile hardware like laptops, this is a terribly scary thing to see inside GPO filtering settings. You probably don't want all of your laptops to immediately start getting DA connectivity settings, but that is exactly what the GSW does for you. Perhaps worst, the GSW will create and make use of self-signed SSL certificates to validate its web traffic, even the traffic coming in from the Internet! This is a terrible practice and is the number one reason that should convince you that clicking on the Getting Started Wizard is not in your best interests.