Book Image

Windows Server 2012 Unified Remote Access Planning and Deployment

Book Image

Windows Server 2012 Unified Remote Access Planning and Deployment

Overview of this book

DirectAccess, introduced in Windows Server 2008 R2, has been a ground breaking VPN-like connectivity solution, adopted by thousands of organizations worldwide. Allowing organizations to deploy without manually configuring every client and providing always-on connectivity has made this technology world-famous. Now, with Windows Server 2012, this has been made even easier to deploy, with a new friendly user interface, easy-start wizard and built in support tools.With Unified Remote Access, Windows server 2012 offers a unique way to provide remote access that is seamless and easier to deploy than traditional VPN solutions. With URA, the successor to DirectAccess, your users can have full network connectivity that is always-on. If you have deployed Windows Server 2012 or are planning to, this book will help you implement Unified Remote Access from concept to completion in no time!Unified Remote Access, the successor to DirectAccess, offers a new approach to remote access, as well as several deployment scenarios to best suit your organization and needs. This book will take you through the design, planning, implementation and support for URA, from start to finish."Windows Server 2012 Unified Remote Access Planning and Deployment" starts by exploring the mechanisms and infrastructure that are the backbone of URA, and then explores the various available scenarios and options. As you go through them, you will easily understand the ideal deployment for your own organization, and be ready to deploy quickly and easily. Whether you are looking into the simplest deployment, or a complex, multi-site or cloud scenario, "Windows Server 2012 Unified Remote Access Planning and Deployment" will provide all the answers and tools you will need to complete a successful deployment.
Table of Contents (17 chapters)
Windows Server 2012 Unified Remote Access Planning and Deployment
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Public Key Infrastructure (PKI)


The role of PKI (Public Key Infrastructure) in URA is important to understand. With Windows 2008 R2, it was required to deploy certificates to every computer that needed to be a DirectAccess client, but this is no longer a mandatory requirement today, thanks to a component that proxies Kerberos authentication instead of using a certificate for the IPSec authentication. It's important to note, though, that this component can be used only if all your URA clients are Windows 8 clients. If you will be deploying this to the Windows 7 clients, you will still require this infrastructure, and we will discuss this in more details in the next chapter.

Even if you choose to deploy URA without issuing certificates to clients, there are other certificate requirements. Earlier, we mentioned that one of the IPv4-IPv6 transition technologies is IP-HTTPS. This requires the URA server and client to communicate with SSL, and for that, you will require a certificate. This can be achieved with a self-signed certificate, produced by the URA server as part of the setup, and it even publishes the root certificate through Active Directory so that your clients can trust it with no need for manual intervention.

The certificate used for this purpose is a server certificate and will be presented to the URA client by the URA server as a means of proving its authenticity. If you prefer, you can use a regular certificate, which can be purchased from any of the many commercial certificate providers such as Verisign, Thawte, and Geotrust. Using a public certificate provider for this situation has costs, of course. Another option is to use the Windows Certificate Authority role that's built into every Windows Server product and create a regular certificate at no cost. The challenge with using an "internal" certificate provider like that is the fact that all your URA clients will have to trust it, which means that if it's not integrated into your domain, you will have to find some way to deploy its root certificate to all clients. Another challenge is that a certificate generated by a certificate authority contains a CRL (Certificate Revocation List), which needs to be accessible to the client as part of the connection process. For this to work, you will need to publish the CRL to some publicly accessible website, and that may be somewhat challenging. We will discuss this topic in more details later on, but you can prepare for this by reading up on managing a Windows certificate authority through the article available at http://technet.microsoft.com/en-us/library/cc738069(v=ws.10).aspx.