فا

‫ Windows Server 2012: What's New in Security - DirectAccess Improvements

IRCAR201209151
Date: 2012-09-19
In this multi-part series, we'll take a look at what's new (and what's not) in security for Windows Server 2012.
Introduction
It's official: The next version of Windows Server has a name and that name indicates it will be released sometime before the end of the year. Whether and when to deploy a new server OS is always a big decision, and most enterprises won't be rolling it out immediately. But part of that decision-making process involves evaluating the relative benefits, and better security is always high on the list of factors that can make all the hassles involved in an upgrade worthwhile. So in this multi-part series, we'll take a look at what's new (and what's not) in security for Windows Server 2012.
First, we’re going to look at the big improvements that have come to DirectAccess. Server 2008 R2 included DirectAccess – but it wasn’t very functional. DirectAccess is a great technology that allows users to connect a remote computer to a work network without the hassle of setting up and using VPN software; the connection is automatic and easy. From the admin side, it allows you to update the remote computer’s software and Group Policy settings even if the user isn’t logged in.
DirectAccess is an important security feature because it gives you much more control over the remote machines that connect to your corporate network. It authenticates the remote computers, encrypts communications via IPsec and lets you configure access controls to specify what resources each user can access.
Server 2012 has brought the UAG DA functionality into Windows Server, so that you don’t have to buy another (expensive) server software package. Microsoft has also added some new capabilities that UAG didn’t have.
Considerations for Windows Server 2012 DirectAccess
Microsoft recommends that you use NAT64 as your IPv6 to IPv4 technology, rather than ISATAP. If you migrate from a UAG server that is using ISATAP, you should disable it and enable NAT64. Of course, native IPv6 will give you the most flexibility.
Enabling and deploying DirectAccess in Server 2012
Now let’s take a closer look at DirectAccess in Server 2012. DirectAccess is enabled as a server role (Remote Access), which you can add through the Server Manager dashboard, as shown in the figure below.
To add the Remote Access role, you run the Add Roles and Features Wizard that helps you install roles, services and features. After selecting the installation type (in this case, role-based or feature-based installation) and selecting the server on which you want to install the role, check the Remote Access box on the “Select Server Roles” page of the wizard. This will bring up a list of role services and features that must be installed before you can install DirectAccess. To do so, click Add Features, as shown in the next figure.
You might look for DirectAcess on the Features page of the wizard, shown in the next figure, but you won’t find it in the list. Don’t worry; we’ll get to it in a moment. For now, just accept the default features and click Next.
Go through the next few pages and then you’ll find the option to select the DirectAccess and VPN role services when you get to that page of the wizard, as shown in the next figure. In fact, it is selected by default, so just click Next.
On the last page of the wizard, look over your installation selections and be sure “DirectAccess and VPN (RAS)” is shown under the Remote Access section. You’ll need to check the box to restart the destination server automatically if required, and then you can click Next.
The installation process, shown in the next figure, can take a while.
Once you’ve enabled the Remote Access role, it’s time to configure DirectAccess on the server. You can deploy DirectAccess only, or deploy both DirectAccess and VPN so that remote client computers that don’t support DirectAccess (pre-Windows 7) can connect to the server over a VPN connection.
The Remote Access configuration wizard will first check to make sure you have all the prerequisites in place. Then you select the network topology of your server (whether it’s on the edge of the network, behind an edge device with two network adapters, or behind an edge device with a single network adapter). You also will need to enter the public name or public IPv4 address that will be used by the remote client computer to connect to the network.
The wizard will do most of the heavy lifting for you, including configuring Kerberos proxy so that you don’t have to set up an internal Public Key Infrastructure – thus saving a ton of time and effort. The wizard provisions self-signed certificates for IP-HTTPS and the Network Location Server. In addition, the wizard will enable NAT64 and DNS64 if you have an IPv4 environment. Note that you can only use the self-signed IP-HTTPS certificate in a single server configuration. If you have multiple servers/multi-site scenario, you’ll need a public IP-HTTPS certificate.
Managing DirectAccess in Server 2012
If you used DirectAccess in Server 2008 R2, you’ll notice that the DirectAccess Management console has gone missing in Server 2012. Instead, you manage DirectAccess by using the Remote Access Management console, which you can access from the Server Manager’s dashboard, as shown in the next figure.
The Remote Access Management console itself looks very similar to the DirectAccess Management console in Server 2008 R2, but with some added features such as the ability to manage DirectAccess and VPN remotely.
Deploying DirectAccess on the client computers
The next step that you need to take in order to get DirectAccess on Server 2012 up and running is to enable DirectAccess for the managed client computers. In the DirectAccess Client Setup, you will choose between two deployment scenarios: You can either select Full DirectAccess (which enables the clients to connect to the internal network) or Manage Out (for using DirectAccess only to manage client computers remotely). This is shown in the figure below.
The Manage Out option wasn’t available in Server 2008 R2; you had to have UAG to get that (it was called “Remote Management”). The way this works is that instead of having two IPsec tunnels as you do in the normal client connection scenario, you have only the infrastructure tunnel.
You select one or more security groups of client computers to enable for DirectAccess. You’ll also select how to authenticate your DirectAccess users: through Active Directory credentials or two-factor authentication (smart cards or One Time Passwords), as shown in the next figure.
You can use an intermediate certification authority to issue the computer certificates, or you can browse for a CA. You can also select whether to enable Windows 7 client computers to connect via DirectAcess and whether to enforce corporate compliance for DirectAccess clients with Network Access Protection (NAP).
You’ll also have to configure the infrastructure servers that DirectAccess clients will access before they can connect to resources on the internal network. A highly available Network Location server is required for DirectAccess, and Microsoft recommends that this server be deployed with a server infrastructure such as domain controllers. You can also run the Network Location server on the DirectAccess server (in which case, the DirectAccess server needs to be highly available). DirectAccess connectivity can be disrupted if the Network Location server becomes unavailable.
Further steps include:
  1. Configuring DNS (setting up a list of DNS suffixes to be used by client computers to determine which DNS queries should be directed to the internal DNS servers).
  2. Configure use of management servers (HRA and SCCM).
  3. Application server setup (select whether to require end-to-end authentication and if you do, select the security groups of the servers that require authentication).
At this point, DirectAccess should be ready to roll. In later articles, we’ll look at how to configure different scenarios and how to troubleshoot problems with DirectAccess in Windows Server 2012.
References:
http://www.windowsecurity.com/

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها: 0