Directaccess supports windows 7 and later remote access clients by default.

Creating a certificate revocation list (CRL) distribution point on the DirectAccess server

In this section, we will configure a location on the DirectAccess server to store the CRL for clients connecting to the server. We will make this CRL web enabled by creating an IIS Web site on the DirectAccess server. We will then configure the Certificate Authority to publish the CRL to the DirectAccess server via a shared folder. To accomplish the above tasks, perform the following:

Log on to the DirectAccess server (LABDA1) and create a new folder on the root of C: named CRL (see Figure 13.31).

Add the Web server role by opening Server Manager.

Then select the Roles node and click the Add Roles link in the middle pane.

Click Next to begin the Add Roles Wizard.

Select the Web Server (IIS) role as seen in Figure 13.32. Then click Next.

On the Introduction page click Next.

Accept the default role services and click Next.

Verify settings on the Confirmation Page. Then click Install.

When the installation is complete, click Close to close the Add Roles Wizard.

To create a Web site which will be used for web CRL distribution, perform the following:

Open Server Manager and expand the Roles | Web Server (IIS) nodes.

Select the newly added Internet Information Services (IIS) Manager node.

In the middle pane, expand the Sites node to reveal the Default Website.

Select the Default Website and then click the Basic Settings link in the right pane.

Change the Physical path to point to the CRL folder that you previously created (see Figure 13.33). Then click OK.

In the middle pane, double-click the Directory Browsing option. Then click the Enable link in the right actions pane as seen in Figure 13.34.

Close Server Manager.

We now need to share the CRL folder and give the Certificate Authority permission to access it. Perform the following steps to set up the CRL shared folder:

Browse to the CRL folder you previously created at the root of C:\. Right-click the CRL folder and choose Properties.

Select the Sharing tab and click the Advanced Sharing button as seen in Figure 13.35.

Click the Share this folder checkbox in the Advanced Sharing window. Then click the Permissions button (see Figure 13.36).

Click the Add button. Then click Object Types.

From the Object Types window, select Computers as seen in Figure 13.37. Then click OK.

Enter the name of the Certificate Authority computer and click OK.

Allow the CA computer Full Control permissions. Then click OK.

Click OK on the Advanced Sharing window and click Close on the Properties window.

You now need to enable the server as a CRL distribution point and publish the CRL to the distribution point. Perform the following to complete these tasks:

Log on to the Certificate Authority and Open Server Manager.

Expand the nodes Roles | Active Directory Certificate Services.

Right click the node representing the Certificate Authority, and select Properties (see Figure 13.38).

Select the Extensions tab in the CA Properties window.

Click Add to add a new CRL distribution point.

Enter the URL you wish to use for the CRL located on the DirectAccess server.

Select the variable and click Insert.

Select the variable and click Insert.

Select the variable as seen in Figure 13.39. Then click Insert.

Go to the end of the long URL string created in the Location field and enter a .crl at the end of the string. Then click OK.

Select the options Include CRLs. Clients use this to find Delta CRL locations and Include in the CDP extension of issued certificates.

Click the Add button.

In the Location text box, enter\\locationofDAServer\CRL\ (see Figure 13.40).

Select the variable and click Insert.

Select the variable and click Insert.

Select the variable and click Insert.

Again add .crl to the end of the newly created location string as seen in Figure 13.41.

Select the option Publish CRLs to this Location.

Select the option Publish Delta CRLs to this Location (see Figure 13.42) and click OK.

When prompted to restart Active Directory Certificate Services, click Yes.

Expand the Certificate Authority node within Server Manager.

Right click on the Revoked Certificates node and select All Tasks | Publish.

Choose the option New CRL and click OK. This will publish the full CRL to the path, making it accessible via file share and the default Web site on the DirectAccess server.

Administrator's Punch List

▪

The simplified DirectAccess wizard is targeted at small- and medium-sized businesses

You can now deploy a DirectAccess server with a single NIC with a single private IP address

The simplified DirectAccess wizard does not support complex enterprise scenarios

When using a single NIC, only the IP-HTTPS protocol is available to DirectAccess clients

When you add support for Windows 7 clients, the DirectAccess server will not use the Kerberos proxy

If using Windows 8, remember that only Windows 8 Enterprise Edition is supported as a DirectAccess client

The simplified DirectAccess wizard deploys the Network Location Server on the DirectAccess server

If using a single NIC deployment with the simplified DirectAccess server, an ISATAP server will not be configured

The RRAS Unified Server Role

In Windows Server 2008 R2, the configuration of RRAS VPNs was completely separate from DirectAccess (DA) configuration. You cannot run an RRAS server on the same Windows Server 2008 R2 edge server that serves as a DirectAccess server. This did not really make sense. DirectAccess, despite all of its benefits, has one big limitation. It only works with clients that:

Are running Windows 7 Enterprise/Ultimate or Windows 8 Enterprise, and

Are members of the Windows domain

Here is the problem: As of October 2012, Windows XP still had slightly over 36% of operating system market share, according to statistics published by NetMarketShare.4 A healthy chunk of that includes businesses that had not yet migrated from Windows XP to a later version of Windows, even though extended support for XP will end in 2014. Many companies apparently plan to hang onto their XP machines until the very end. Those XP computers cannot be configured as DirectAccess clients.

But that is a temporary problem; eventually, the XP computers will be replaced by clients running more modern operating systems. However, in addition to these legacy clients, there are also Windows 7 client systems that need to connect to the corporate network but that, for whatever reasons, are not members of the domain. Thus, a significant number of network administrators are faced with managing remote access for both DirectAccess clients and clients that need another remote access solution.

It would seem to be more logical and convenient to combine the management tools for DA and RRAS. With Windows Server 2012, Microsoft went a step further than that and combined DA and RRAS into a new unified server role, which allows administrators to configure, manage, and monitor both the DirectAccess and VPN services together. Now DA and RRAS can coexist on the same server. This was made possible by the modification of IKEv2 policies and IPsec Denial of Service Protection (DoSP) in the following ways:

Now IKEv2 policies allow IPv6 transition technology traffic.

DoSP no longer drops all IPv4 packets, and IPv6 packets are not protected by IPsec as it did in the previous implementation.

Thanks to these changes, you no longer have to have two separate servers for running DA and RRAS and you do not have to switch back and forth between different interfaces to configure them. You can deploy and manage your RRAS VPNs (and DA) in one of two ways: through the graphical interface with the management console, or via the command line with PowerShell. Many organizations are now deploying Server Core installations to enhance performance and reduce the attack surface for network servers. You can install the RRAS Server role on a Server Core server.

Selecting a DirectAccess model

Before jumping headlong into a DirectAccess deployment, the first step an administrator must take is to determine the DirectAccess model they would like to employ. The level of security required across organizations will vary in stringency, and administrators have the choice to build a design that maps to the organization's specific security needs. Microsoft defines three DirectAccess models that can be evaluated to determine the architecture that is a best fit for your environment. The three main access models that we will discuss are:

Full Intranet Access

Selected Server Access

End-to-End Access

In some environments, the thought of allowing access to internal protected company resources from the Internet seems daunting, while in others, the accessibility is readily welcomed. Regardless of the security stance of your organization, you can build a secure access model to meet your business need. All three of the access models follow some of the same security principles and contain the same infrastructure elements. Let us review the high-level similarities across the three access models first.

The first commonality is: to ensure that data transference is secure when traversing the Internet, DirectAccess utilizes a two-step IPsec Encapsulating Security Payload (ESP) tunnel to connect. The first connection made by the client regardless of the access model will always be an infrastructure tunnel. The Infrastructure tunnel enforces computer authentication.