Secure Remote Access: A Step-by-Step Guide to Installing DirectAccess on Windows Server

Table of Contents

DirectAccess represents a significant advancement in providing seamless and secure remote access to organizational resources for users connected to the internet. Unlike traditional VPNs, which require users to manually initiate a connection and often provide credentials, DirectAccess offers an “always-on” experience. Once a DirectAccess client is connected to the internet, it automatically establishes a secure connection to the internal network, allowing users to access company file shares, applications, and other resources without any manual intervention. This capability not only enhances user productivity but also simplifies remote management of client computers, even when they are not physically connected to the corporate LAN.

At its core, DirectAccess leverages IPv6 transitions technologies and IPsec encryption to create secure tunnels between the remote client and the internal network. It’s designed to provide bidirectional connectivity, meaning administrators can manage remote DirectAccess clients just as easily as they manage devices within the corporate perimeter. This is particularly valuable for applying Group Policy Objects (GPOs), deploying software updates, or troubleshooting issues on remote machines. DirectAccess requires careful planning and configuration, typically involving integration with Active Directory, Public Key Infrastructure (PKI), and potentially Network Location Server (NLS).

To successfully implement DirectAccess on a Windows Server, several prerequisites must be met. These typically include a server running a compatible Windows Server operating system (like Server 2012 R2, 2016, 2019, or 2022), which is joined to an Active Directory domain. The server should have at least one network adapter connected to the internet (external) and ideally another connected to the internal network. Publicly registered DNS records and appropriate firewall configurations are also crucial for external client connectivity. A functional PKI infrastructure is highly recommended, often required for client and server authentication using computer certificates.

The installation and configuration process for DirectAccess involves several distinct steps. Each step builds upon the previous one, laying the groundwork for a robust and reliable remote access solution. Starting with the necessary server roles and features, the process moves through essential network configuration, security group management, certificate enrollment, and DNS record creation before finally enabling the DirectAccess feature itself. Attention to detail at each stage is paramount to ensure successful deployment and operation.

Here is a detailed breakdown of the steps required to install and configure DirectAccess on Windows Server:

How to Install and Configure DirectAccess on Windows Server¶

Deploying DirectAccess on Windows Server involves several key stages. Follow these steps carefully to set up this secure remote access solution.

1] Install Remote Access Management Role¶

The foundational step is installing the necessary server role and features that provide the tools and services required for DirectAccess. The ‘Remote Access’ role includes DirectAccess, VPN (RAS), and Web Application Proxy services. Installing this role brings the graphical management console and associated PowerShell cmdlets needed for configuration.

Begin by opening Server Manager on your Windows Server. Navigate to the ‘Configure the local server’ section and click on ‘Add roles and features’. This action launches the ‘Add Roles and Features Wizard’, which guides you through the process. Click ‘Next’ to proceed past the initial welcome page. Choose ‘Role-based or feature-based installation’ on the Installation Type page, as you are adding a specific server role to the selected server.

On the Server Selection page, ensure that ‘Select a server from the server pool’ is checked and that your target server is highlighted. Click ‘Next’. The Server Roles page lists available roles. Here, you need to select ‘Remote Access’. Selecting this role will often prompt you to add required features. Click ‘Add Features’ in the pop-up window.

After adding the Remote Access role, click ‘Next’. On the Features page, while the wizard might automatically select necessary features, you might need to manually select ‘Remote Access Management Tools’ if it wasn’t automatically included. This feature provides the Remote Access Management Console, which is essential for configuring DirectAccess. Ensure all necessary sub-features or management tools are selected. Click ‘Next’. Review the information on the Role Services page, confirming that ‘DirectAccess and VPN (RAS)’ is listed under the Remote Access role. Click ‘Next’. On the Confirmation page, review your selections and click ‘Install’. The installation process may take several minutes. Once complete, close the wizard.

2] Configure Static IP Address¶

A stable network configuration is critical for a server hosting DirectAccess. The external network adapter of the DirectAccess server should ideally have a static public IP address. If the server is behind a NAT device (a common configuration, especially for a single-server deployment), the external interface will have a static private IP, but the public IP mapped to it must be static and reachable. For simplicity and reliability, especially in enterprise environments, using static IPs for server roles like DirectAccess is standard practice.

To configure a static IP address, open Server Manager. In the left-hand pane, click on ‘Local Server’. In the main panel, find the ‘Ethernet’ entry (or the name of your network adapter) and click on the hyperlink next to it, which typically displays the current IP configuration. This opens the Network Connections window. Right-click on the network adapter you want to configure (usually the one connected to the internal network for server functions, or the external one if that’s what you’re configuring for this purpose) and select ‘Properties’.

In the properties window, scroll down to find ‘Internet Protocol Version 4 (TCP/IPv4)’, select it, and click the ‘Properties’ button. On the ‘Internet Protocol Version 4 (TCP/IPv4) Properties’ window, select the option ‘Use the following IP address’. Enter the static IP address, subnet mask, and default gateway appropriate for your internal network segment. Then, under ‘Use the following DNS server addresses’, enter the IP address of your internal DNS server (which is typically your Active Directory Domain Controller). Ensure these details are correct for reliable internal network communication. Click ‘OK’ to save the changes and close the network adapter properties.

Configuring a static IP ensures the server is consistently reachable on the network, which is vital for DirectAccess operations and reliable server management. This step is a fundamental networking best practice for any server hosting critical services.

3] Create a New Security Group, Grant Permissions, and Enroll Certificates¶

DirectAccess policies are applied to specific groups of client computers, not individual users. This requires creating a dedicated security group in Active Directory to manage which machines receive the DirectAccess configuration. Furthermore, certificate authentication is a core component of DirectAccess security, often involving machine certificates issued by an internal Public Key Infrastructure (PKI). Configuring permissions on certificate templates is necessary to allow relevant entities to request these certificates.

First, let’s create the security group. Open Server Manager. Go to ‘Tools’ and select ‘Active Directory Users and Computers’. Expand your domain name in the left pane. Navigate to the container where you want to create the group (commonly ‘Users’ or a dedicated ‘Groups’ Organizational Unit). Right-click in the right-hand pane, select ‘New’, and then click ‘Group’. Provide a meaningful name for the group, such as “DirectAccess Clients” or “DA_Computers”. Leave the Group scope (e.g., Global) and Group type (Security) as their defaults unless your specific AD design requires otherwise. Click ‘OK’ to create the group. You will later add the computer accounts of the machines you want to enable for DirectAccess to this group.

Next, configure permissions for certificate enrollment. DirectAccess typically relies on computer certificates for authentication. If you are using an internal Certificate Authority (CA), you need to ensure that the computer accounts or the security group created have permissions to request certificates based on a relevant template, often the ‘Workstation Authentication’ or ‘Computer’ template. In some configurations, particularly those involving multi-site or complex setups, the ‘Web Server’ template might also be involved, especially for the Network Location Server (NLS). Let’s focus on the ‘Web Server’ template permission as mentioned in the original text for NLS. Open Server Manager, go to ‘Tools’, and select ‘Certification Authority’. Right-click on ‘Certificate Templates’ in the CA console and click ‘Manage’. This opens the Certificate Templates Console.

Find the ‘Web Server’ template in the list. Right-click on it and select ‘Properties’. Go to the ‘Security’ tab. Here you define which security principals (users, groups, computers) have permissions to read, write, or enroll certificates using this template. To allow the NLS server or other components to obtain a Web Server certificate, ensure the relevant computer account (the DirectAccess server’s computer account if it hosts NLS) or a group it is a member of has ‘Read’ and ‘Enroll’ permissions. The original text mentions granting ‘Full Control’ to ‘Authenticated Users’ for the ‘Web Server’ template. While this grants broad access, it might be overly permissive depending on your security posture. A more granular approach would be to grant ‘Read’ and ‘Enroll’ permissions to the computer account of the DirectAccess server or a dedicated service account running the NLS role. Verify your PKI best practices before making broad permission changes. After configuring permissions, click ‘Apply’ and ‘OK’. For these permission changes to take effect, you must restart the Active Directory Certificate Services (AD CS) service. Open PowerShell as Administrator and run the command: Restart-Service certsvc.

Finally, enroll the NLS server certificate. The Network Location Server is a critical component of DirectAccess. Client computers use the NLS to determine if they are inside or outside the corporate network. The NLS must be resolvable only from inside the corporate network and accessed via HTTPS using a valid SSL certificate. This certificate needs to be enrolled on the server hosting the NLS role (often the DirectAccess server itself). The certificate should be issued to a name that is internal-only (e.g., DirectAccess-NLS.yourdomain.local). Search for and open “Manage user certificates” (or ‘certmgr.msc’). Expand ‘Personal’, right-click on ‘Certificates’, and select ‘All Tasks’ > ‘Request New Certificate’. Click ‘Next’ on the Certificate Enrollment wizard pages until you reach the ‘Request Certificates’ page. Select the ‘Web Server’ template (or the appropriate template configured for NLS). Click the link “More information is required to enroll for the certificate. Click here to configure settings.”

In the Certificate Properties dialog, under the ‘Subject’ tab, set the ‘Type’ to ‘Common name’. Enter the internal, non-internet-resolvable FQDN for your NLS server in the ‘Value’ field (e.g., DirectAccess-NLS.yourdomain.local). Click ‘Add’. You might also add the DNS name under the ‘Alternative name’ section as a DNS type. Go to the ‘General’ tab and provide a friendly name if desired. Go to the ‘Private Key’ tab and ensure the key is exportable if you plan to use the certificate on multiple servers (less common for NLS on the DA server itself). Go to the ‘Extensions’ tab and verify the Application Policies include Server Authentication. Click ‘OK’ to return to the Certificate Enrollment page. Ensure the template is selected and click ‘Enroll’. Click ‘Finish’ once the enrollment is successful. This certificate will be installed in the Personal store of the user context you used to request it (usually the administrator). You may need to export it and import it into the computer’s certificate store if the NLS service runs under a different context or if you requested it under a user account rather than the computer account directly.

4] Create DirectAccess-NLS A Record¶

As mentioned, the Network Location Server (NLS) must be resolvable only from within the internal network. This is achieved by creating an internal DNS record for the NLS name configured during the certificate enrollment step. This DNS record should point to the IP address of the server hosting the NLS role. DirectAccess clients use this record to determine their location: if they can resolve and reach the NLS server via HTTPS, they assume they are inside the corporate network and DirectAccess is disabled. If they cannot resolve or reach the NLS, they assume they are outside and DirectAccess is activated.

Open Server Manager, go to ‘Tools’, and select ‘DNS Manager’. Expand your server name, then expand ‘Forward Lookup Zones’. Find your internal Active Directory domain forward lookup zone (e.g., yourdomain.local). Right-click on your domain zone and select ‘New Host (A or AAAA)’. In the ‘Name’ field, enter the host name for your NLS server, which is the first part of the FQDN you used for the certificate (e.g., ‘DirectAccess-NLS’). The full FQDN will be displayed below (e.g., DirectAccess-NLS.yourdomain.local). In the ‘IP address’ field, enter the internal IP address of the server that will host the NLS (typically the DirectAccess server itself). Ensure the ‘Create associated pointer (PTR) record’ is checked if you want a reverse lookup entry.

Click ‘Add Host’. You will receive a confirmation message indicating the host record was successfully created. Click ‘OK’. Now, internal clients using your internal DNS server will be able to resolve DirectAccess-NLS.yourdomain.local to the internal IP address, while external clients using public DNS servers will not be able to resolve it, correctly identifying themselves as outside the network.

5] Enable Direct Access¶

With the prerequisites in place, you can now enable and configure DirectAccess using the Remote Access Management Console. This console centralizes the configuration process, allowing you to define client settings, server topology, infrastructure servers, and application servers.

Open Server Manager, go to ‘Tools’, and select ‘Remote Access Management’. If prompted about configuration, you can usually proceed. In the Remote Access Management console, navigate to the ‘Configuration’ tab. You should see options to set up different remote access scenarios. Click on ‘Enable DirectAccess’. This action launches the ‘Enable DirectAccess Wizard’.

On the ‘DirectAccess Clients’ page, you specify which computers will be configured as DirectAccess clients via Group Policy. Click the ‘Add’ button. Use the object picker to select the security group you created earlier (e.g., “DirectAccess Clients”). Click ‘OK’ to add the group. Ensure the group is listed. You have the option to ‘Enable DirectAccess for mobile computers only’; check this if you only want laptops or portable devices to use DirectAccess, leaving desktop machines on the internal network to use traditional methods. This setting targets computers based on the ‘Laptop or Desktop Computer’ attribute in Active Directory. Click ‘Next’.

On the ‘Network Topology’ page, you describe how the DirectAccess server is connected to the network. Select the option that matches your setup: ‘Behind an edge device (with a single network adapter)’ is common if the DirectAccess server is located inside your network perimeter, behind a firewall or router performing NAT. ‘Edge device (with two network adapters)’ is for a server acting as the perimeter device directly connected to both the internet and internal network. For the ‘Behind an edge device’ scenario, you will need to provide the public name or IP address that external clients will use to connect to DirectAccess. This is the public FQDN that resolves to the external IP of your edge device or the DirectAccess server if it has a public IP. Enter this public name (e.g., directaccess.yourcompany.com). Click ‘Next’.

On the ‘Infrastructure Servers’ page, you configure essential servers DirectAccess clients need to reach before establishing full connectivity. This includes the Network Location Server (NLS), DNS servers, and domain controllers. The wizard will often pre-populate some settings based on your server’s configuration. Specify the URL of your NLS server (the internal FQDN you created the A record and certificate for, e.g., https://DirectAccess-NLS.yourdomain.local). You also need to specify the DNS suffixes to be used by DirectAccess clients and the DNS servers they should use (your internal DNS servers). The wizard might automatically detect your domain controllers; verify they are listed correctly. Click ‘Next’.

The ‘Application Servers’ page allows you to restrict DirectAccess connectivity to specific internal servers instead of granting access to the entire internal network. By default, access is granted to all internal resources. If you need to limit access, you can configure this here. For a typical deployment granting access to the full network, you can proceed without making changes unless specific security policies require it. Click ‘Next’.

On the ‘Summary’ page, review all the configuration settings you’ve entered. Pay close attention to the security group, external name, and NLS URL. If everything looks correct, click ‘Finish’. The wizard will then apply the DirectAccess configuration by creating and linking Group Policy Objects (GPOs) to the domain. This process can take several minutes as GPOs are created, populated with settings, and linked.

After the wizard completes, the Remote Access Management Console will show the DirectAccess configuration status in the ‘Dashboard’. It may take some time for the configuration to become active and for the associated GPOs to replicate throughout the domain and apply to the client computers. Refresh the console view periodically. You should see various components indicating a healthy status (often represented by green icons). There might be some warnings or non-critical status indicators depending on your setup (e.g., Teredo status if not needed or configured). Focus on the critical infrastructure and client connectivity statuses.

Potential Configuration & Considerations:

• Certificates: Ensure your internal CA is trusted by client computers. DirectAccess heavily relies on computer certificates for IPsec tunnel authentication. You’ll likely need a GPO to auto-enroll ‘Workstation Authentication’ or ‘Computer’ certificates to client machines in your ‘DirectAccess Clients’ security group.
• Firewall: Appropriate firewall rules are essential on the DirectAccess server and potentially the internal network firewall. DirectAccess uses specific protocols like IPsec (UDP 500, UDP 4500, ESP) and potentially TCP 443 for HTTPS (for the NLS and possibly IP-HTTPS tunnel).
• IPv6: DirectAccess is fundamentally an IPv6 technology. It uses IPv6 transition technologies (like IP-HTTPS or Teredo) to tunnel IPv6 traffic over IPv4 networks (the internet). The server and clients will have IPv6 addresses assigned by DirectAccess. Ensure no conflicting IPv6 configurations exist.
• Group Policy: The DirectAccess configuration is primarily managed through GPOs created by the wizard. Do not manually edit these GPOs unless you are an expert, as it can break the configuration. Ensure these GPOs are linked to an OU containing the client computers or the security group and that GPO processing is not blocked.
• Testing: After configuration, test connectivity from a client computer added to the DirectAccess client group while connected to the internet outside the corporate network. Use ipconfig /all to check the DirectAccess adapter and IPv6 addresses. Use Get-NetAdapter -IncludeHidden in PowerShell to see tunnels. Use Get-NetIPsecTunnel and Get-NetIPsecMainModeSA to check IPsec status. Ping internal resources by name and IP address. Access file shares and internal websites. The Network Connection Status Icon in the system tray should indicate internet access while still allowing access to corporate resources without VPN.

Deploying DirectAccess requires careful planning regarding network topology, firewall rules, DNS strategy, and PKI integration. The steps outlined above provide a solid foundation, but real-world deployments may involve additional considerations based on specific organizational requirements and infrastructure.

How to install and configure Active Directory in Windows Server?¶

DirectAccess is inherently integrated with and relies on Active Directory Domain Services (AD DS). AD DS provides the necessary infrastructure for user and computer authentication, Group Policy management, and DNS resolution required for DirectAccess clients to locate internal resources and receive configuration. If you do not already have an Active Directory domain, you must set one up before deploying DirectAccess.

To install Active Directory Domain Services on a Windows Server, open Server Manager. Click on ‘Add roles and features’. Proceed through the wizard as before until you reach the ‘Server Roles’ page. Here, select ‘Active Directory Domain Services’. When prompted to add required features, click ‘Add Features’. Click ‘Next’ through the remaining pages, reviewing the information, and click ‘Install’. After the role installation is complete, you must promote the server to a domain controller. Click the ‘Promote this server to a domain controller’ link in the Server Manager dashboard or the completion notification. This launches the Active Directory Domain Services Configuration Wizard, where you can choose to add a new domain to an existing forest, add a new domain tree, or add a new forest (if this is your first domain). Follow the prompts to configure the domain, specify domain controller options, DNS settings, and directories for AD DS database, logs, and SYSVOL. A restart is required after the promotion process.

This foundational AD DS setup is critical because DirectAccess relies on Active Directory group membership for client targeting and uses Group Policy Objects (GPOs) created within AD DS to push the DirectAccess configuration to clients. Reliable DNS, provided by the domain controller, is also essential for clients to resolve internal resource names.

Implementing DirectAccess is a powerful way to enhance remote productivity and management. While the initial setup involves several steps covering networking, security, and identity management, the resulting “always-on, always-managed” connectivity provides significant benefits for both users and IT administrators. Careful planning and execution of each step are key to a successful deployment.

Have you implemented DirectAccess in your environment, or are you planning to? Share your experiences, challenges, or questions in the comments below!