Book Image

Windows Server 2016 Security, Certificates, and Remote Access Cookbook

By : Jordan Krause
Book Image

Windows Server 2016 Security, Certificates, and Remote Access Cookbook

By: Jordan Krause

Overview of this book

<p>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. </p> <p>You will learn tips for configuring proper networking, especially on multi-homed systems, and tricks for locking down access to your servers.</p> <p>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.</p> <p>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. </p> <p>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.</p>
Table of Contents (9 chapters)
Title Page
Packt Upsell
Contributors
Preface
Index

Building a Subordinate certification authority server


We build Subordinate CAs not really for the purposes of redundancy, like with many other kinds of servers, but because there are specific tasks that you may want to perform on a subordinate CA rather than a Root CA. If you issue a lot of certificates or different kinds of certificates, you may want to differentiate between CA servers when issuing. Perhaps you want machine certificates that are used for IPsec to be issued from IPSEC-CA, but the SSL website certificates that you issue should show as being issued from WEB-CA. Rather than building out two independent Root CAs that both have top-level rights, you should consider creating a single Root CA, maybe called ROOT-CA, and placing these two CA servers in a subordinate role under the Root CA in the chain. This can also be useful for geographically dispersed networks, having Subordinate CA servers dedicated to assigning certificates for different offices or regions.

As we discussed in...