Remote Network Access: Objectives and Architecture
In the this mini-series, I am going to diverge from my usual System Center-only focus to take a fresh look at deploying a Microsoft Remote Network Access solution. First, we’ll get you online and working using SSTP, and then extend this base implementation with Network Access protection before finally coming back a little later and elevating these SSTP servers to Direct Access.
Don’t miss the other two parts of this series!
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
Why Remote Network Access?
So why I am doing this? As we build out solutions for System Center, we need a foundation from which to work, and within the latest versions of Configuration Manager we have the ability to integrate with the Windows Network Access Protection and manage our off-site computers with a dial out approach over Direct Access. Also, in the new R2 releases we can integrate both our Certificate Servers (Certificate Authority – CAs) and we finally have the ability to distribute VPN Profiles to our end users. Therefore, I am considering this miniseries as a foundation for illustrating these features and abilities in later posts.
I am building this solution out using the recently published RTM builds of Windows Server 2012 R2, but almost everything I will cover in this series will work from 2008 R2, with some minor adjustments and wizard changes.
The environment which we will use for the scenarios is illustrated in the graphic below, showing our client establishing a connection with the RRAS server over TCP443 or what you might better recognize as the HTTPS port. SSTP utilizes this same supporting environment, including the SSL certificates used to protect the tunnel.
I have tagged a number of the components with a to indicate the initial systems which are engaged in the basic SSTP implementation, including the Network Policy Server (otherwise known as RADIUS), which is used to check the client’s authorization to proceed with establishing the requested tunnel.
The remaining servers are added to the scenario as we enable the NAP services, including the Certification Authority, and as an example, a simple Windows Update Server to offer simple remediation to non-compliant clients.
Each of the servers are responsible for different roles in the overall solution. To get a brief understanding of what these are, let’s take a quick look at their primary functions.
- NPS Server – This hosts the Network Policy Services and Network Access Protection services. This server can also be referred to as the Radius Server. When we extend the solution with support for Network Access Protection, we will add a second role to this server called Health Replication Authority (HRA), which will connect to our Certificate Server to request and Issue health certificates
- SSTP Server – This server hosts the actual Routing and Remote access installation. It will be configured to primarily offer SSTP-only tunnels, and it will connect to the NPS server for authentication and accounting (storing auditing) information, with the purpose of determining if the clients are indeed permitted to establish the tunnels
- CA Servers – These host PKI certificate templates and issues certificates based on these templates to our systems. It is also responsible for issuing the Health Certificates via the Health Responsibility Authority. We will need to actually create the templates for these Health Certificates as part of the deployment.
- Client Computers – These are domain-joined machines that will subscribe to the new SSTP service that we are implementing. SSTP is supported from Windows 7 and newer versions of the client. Non-domain-joined machines can of course work with SSTP, but for the scope of this mini-series I am focusing on domain-joined systems.
We now have the background and an idea of how the different servers will be used. Our next objective will be to implement this solution. Now would be a great time to get your environment ready and spin up some servers for the jobs we are about to face.