Windows Server 2016 Security, Certificates, and Remote Access Cookbook

Jordan Krause

• Editore: Packt Publishing
• Anno: 2018
• ISBN:
  9781789135220
• Edizione: 1
• Argomento: Computer Science
• Categoria: System Administration

This book contains more than 25 hands-on recipes that will equip you to build a PKI and roll out remote access capabilities via Microsoft DirectAccess and VPN. This book also contains tips and tricks for increasing the security footprint of your Windows Server infrastructure.

Key Features

• Identify and mitigate security risks in your Windows Server 2016 infrastructure
• Learn how to build a PKI and use it to issue certificates within your network
• In-depth information for setting up Microsoft DirectAccess

Book Description

Windows Server 2016 is an operating system designed to run on today's highly performant servers, both on-premise and in the cloud. It supports enterprise-level data storage, communications, management, and applications. This book builds off a basic knowledge of the Windows Server operating system, and assists administrators with taking the security of their systems one step further.

You will learn tips for configuring proper networking, especially on multi-homed systems, and tricks for locking down access to your servers.

Then you will move onto one of the hottest security topics of the year – certificates. You will learn how to build your own PKI, or how to better administer one that you already have. You will publish templates, issue certificates, and even configure autoenrollment in your network.

When we say "networking" we don't only mean inside the LAN. To deal safely with mobile devices, you will learn about the capabilities of Windows Server 2016 for connecting these assets securely back into the corporate network, with information about DirectAccess and VPN.

The material in the book has been selected from the content of Packt's Windows Server 2016 Cookbook by Jordan Krause to provide a specific focus on these key Windows Server tasks.

What you will learn

• Implement solid networking and security practices into your Windows Server environment
• Design your own PKI and start issuing certificates today
• Connect your remote laptops back to the corporate network using Microsoft's own remote access technologies, including DirectAccess
• Learn to use commands that will help you with monitoring network traffic.
• Build and explore your first Server Core instance today!

Who this book is for

If you are a Windows Server administrator interested in learning the key security and networking functions available in Windows Server 2016, keep this book close at hand. If you are a server administrator setting up certificate services for the first time you will also benefit from the step-by-step instructions on implementation of a PKI.

Remote Access

With Windows Server 2016, Microsoft brings a whole new way of looking at remote access. Companies have historically relied on third-party tools to connect remote users to the network, such as traditional and SSL VPN provided by appliances from large networking vendors. I'm here to tell you those days are gone. Those of us running Microsoft-centric shops can now rely on Microsoft technologies to connect our remote workforce. Better yet is that these technologies are included with the Server 2016 operating system, and have functionality that is much improved over anything that a traditional VPN can provide.

Regular VPN does still have a place in the remote access space, and the great news is that you can also provide it with Server 2016. In fact, by now many of you have probably heard of a "new" remote access technology in Server 2016 called Always On VPN. I put the word new in quotes because the VPN technology on the server side has actually not changed at all, it is Windows 10 on the client side that has been adjusted to introduce this new way of creating VPN connections. In Windows Server 2016 (or any version of Windows Server), your setup procedures for Always On VPN are the same as any VPN access. When you look into whether or not you want to provide Always On VPN to your workforce, you are really exploring a client-side technology that was introduced in Windows 10 1709.

We have some recipes on setting up VPN, but our primary focus for this chapter will be DirectAccess (DA). DA is kind of like automatic VPN. There is nothing the user needs to do in order to be connected to work. Whenever they are on the Internet, they are connected automatically to the corporate network. DirectAccess is an amazing way to have your Windows 7, Windows 8, and Windows 10 domain joined systems connected back to the network for data access and for the secure management of those traveling machines. DA has actually been around since 2008, but the first version came with some steep infrastructure requirements and was not widely used. Server 2016 brings a whole new set of advantages and makes implementation much easier than in the past.

There is currently a lot of confusion around the topics of DirectAccess and Always On VPN, and unfortunately many people are wondering if one is going to replace the other. Based on my experience and knowledge about how these things work, they actually supplement each other. When having discussions with customers about what remote access technology fits better into their environment, it's not always a matter of either/or, oftentimes it is both. DirectAccess definitely holds some advantages over AOVPN when you are talking about the best way to connect your domain-joined, corporate laptops. However, if you are interested in BYOD and providing users the ability to connect their personal computers or devices to your corporate network, that is where AOVPN can bring some functionality to the table that DA cannot. I still find many server and networking admins who have never heard of DirectAccess, so let's spend some time together exploring some of the common tasks associated with it.

In this chapter, we will cover the following recipes:

• DirectAccess planning question and answers
• Configuring DirectAccess, VPN, or a combination of the two
• Pre-staging Group Policy Objects to be used by DirectAccess
• Enhancing the security of DirectAccess by requiring certificate authentication
• Building your Network Location Server on its own system
• Enabling Network Load Balancing on your DirectAccess servers
• Adding VPN to your existing DirectAccess server
• Replacing your expiring IP-HTTPS certificate
• Reporting on DirectAccess and VPN connections

Introduction

There are two flavors of remote access available in Windows Server 2016. The most common way to implement the Remote Access role is to provide DirectAccess for your Windows 7, 8, and 10 domain-joined client computers, and VPN for the rest. The DA machines are typically your company-owned corporate assets. One of the primary reasons why DirectAccess is usually only for company assets is that the client machines must be joined to your domain because the DA configuration settings are brought down to the client through a GPO. I doubt you want the home and personal computers joining your domain.

VPN is therefore used for down-level clients or non-domain-joined Windows 7/8/10, and for home and personal devices that want to access the network. Since this is a traditional VPN listener with all regular protocols available such as PPTP, L2TP, SSTP and IKEv2, it can even work to connect devices such as smartphones and tablets to your network.

There is a third function available within the Server 2016 Remote Access role called the Web Application Proxy (WAP). This function is not used for connecting remote computers fully into the network such as is the case with DirectAccess and VPN; rather, WAP is used for publishing internal web resources out to the Internet. For example, if you are running Exchange and SharePoint Server inside your network and want to publish access to these web-based resources to the Internet for external users to connect to, WAP would be a mechanism that could publish access to these resources. The term for publishing to the Internet like this is Reverse Proxy, and WAP can act as such. It can also behave as an ADFS Proxy.

For further information on the WAP role, please visit http://technet.microsoft.com/en-us/library/dn584107.aspx.

DirectAccess planning question and answers

One of the most confusing parts about setting up DirectAccess is that there are many different ways to do it. Some are good ideas, while others are not. Before we get rolling with recipes, we are going to cover a series of questions and answers to help guide you towards a successful DA deployment. One of the first questions that always presents itself when setting up DirectAccess is How do I assign IP addresses to my DA server?. This is quite a loaded question because the answer depends on how you plan to implement DA, which features you plan to utilize, and even upon how secure you believe your DA server to be. Let me ask you some questions, pose potential answers to those questions, and discuss the effects of making each decision.

• Which client operating systems can connect using DirectAccess?

Windows 7 Ultimate, Windows 7 Enterprise, Windows 8.x Enterprise, and Windows 10 Enterprise or Education. You'll notice that the Professional SKU is missing from this list. That is correct; Windows 7, Windows 8, and Windows 10 Pro do not contain the DirectAccess connectivity components. Yes, this does mean that Surface Pro tablets cannot utilize DirectAccess out-of-the-box. However, I have seen many companies now install Windows 10 Enterprise onto their Surface tablets, effectively turning them into Surface Enterprises. This works well and does indeed enable them to be DA clients. In fact, I am currently typing this text on a DirectAccess connected Surface Pro turned Enterprise tablet.

• Do I need one or two NICs on my DirectAccess server?

Technically, you could set up either way. In practice, however, it really is designed for dual-NIC implementation. Single NIC DirectAccess works okay sometimes to establish a proof-of-concept to test out the technology, but I have seen too many problems with single NIC implementations in the field to ever recommend it for production use. Stick with two network cards, one facing the internal network and one facing the Internet.

• Do my DirectAccess servers have to be joined to the domain?

Yes.

• Does DirectAccess have site-to-site failover capabilities?

Yes, though only Windows 8.x and 10 client computers can take advantage of it. This functionality is called Multi-Site DirectAccess. Multiple DA servers that are spread out geographically can be joined together in a multi-site array. Windows 8 and 10 client computers keep track of each individual entry point and are able to swing between them as needed or at user preference. Windows 7 clients do not have this capability and will always connect through their primary site.

• What are these things called 6to4, Teredo, and IP-HTTPS that I have seen in the Microsoft documentation?

6to4, Teredo, and IP-HTTPS are all IPv6 transition tunneling protocols. All DirectAccess packets that are moving across the Internet between a DA client and DA server are IPv6 packets. If your internal network is IPv4, then when those packets reach the DirectAccess server they get turned down into IPv4 packets by some special components called DNS64 and NAT64. While these functions handle the translation of packets from IPv6 into IPv4 when necessary inside the corporate network, the key point here is that all DirectAccess packets that are traveling over the Internet part of the connection are always IPv6. Since the majority of the Internet is still IPv4, this means that we must tunnel those IPv6 packets inside something to get them across the Internet. That is the job of 6to4, Teredo, and IP-HTTPS. 6to4 encapsulates IPv6 packets into IPv4 headers and shuttles them around the Internet using protocol 41. Teredo similarly encapsulates IPv6 packets inside IPv4 headers, but then uses UDP port 3544 to transport them. IP-HTTPS encapsulates IPv6 inside IPv4 and then inside HTTP encrypted with TLS, essentially creating an HTTPS stream across the Internet. This, like any HTTPS traffic, utilizes TCP port 443. The DirectAccess traffic traveling inside either kind of...