All posts tagged RDP

WEBINAR: Preparing for 100-Day Certificates with CertKit

Join me and the CertKit team on Tuesday, October 6, 2026, at 9:00 AM PDT for a free, live webinar about the upcoming reduction in public TLS certificate lifetimes. Beginning March 15, 2027, the maximum validity period for public TLS certificates will be reduced to 100 days. This change will make manual certificate management increasingly difficult for many organizations.

Automation

Shorter certificate lifetimes require organizations to identify, enroll, deploy, and renew certificates more frequently. Automation can help reduce the administrative effort and the risk of service interruptions caused by expired certificates. This is especially important for public-facing Microsoft workloads such as Internet Information Services (IIS), Remote Desktop Services (RDS), Always On VPN, DirectAccess, and other services that use public TLS certificates.

Visibility

Effective certificate management begins with knowing which certificates exist, where they are installed, and when they expire. Without this visibility, organizations may overlook certificates until they are close to expiration or have already expired.

Internal Certificates

Certificates issued by a private certification authority (CA) aren’t subject to the lifetime restrictions imposed on public TLS certificates. However, they still require inventory, monitoring, and renewal. A consistent approach to managing public and private certificates can help reduce operational overhead.

How CertKit Helps

CertKit is a cloud-based service for managing public and private TLS certificates. During the webinar, we’ll demonstrate how CertKit provides visibility into certificate inventories and expiration dates while automating common lifecycle tasks such as enrollment, deployment, and renewal. We’ll also review recent additions to the service.

Register Now

The webinar takes place on Tuesday, October 6, at 9:00 AM PDT. Registration is required. Everyone who registers will be notified when the session recording is available.

Leave a comment
by Richard M. Hicks on September 22, 2026  •  Permalink
Posted in Always On VPN, Cloud PKI, DirectAccess, PKI, PowerShell, TLS, Training and Events, Windows Server
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on September 22, 2026

https://directaccess.richardhicks.com/2026/09/22/webinar-preparing-for-100-day-certificates-with-certkit/

Webinar: Certificate Automation in Practice – A Technical Deep Dive

If you manage Windows Server workloads that require public TLS certificates like Always On VPN, DirectAccess, Remote Desktop Gateway, Internet Information Services (IIS), and others, you know that certificate expirations don’t send friendly reminders. Certificates expire quietly. Too often, end users are the ones who sound the alarm—when resources are already unavailable. Of course, this never happens at a convenient time. It’s usually the middle of the night, on the weekend.

Missed the event? Watch the on-demand replay here.

Current State

Most Windows IT teams are still managing certificates the same way they did years ago, using spreadsheets, calendar reminders, and an assortment of renewal scripts. It usually works… until it suddenly doesn’t.

Free Webinar

I’m pleased to announce that I’ll be joining Todd Gardner from CertKit for a free live webinar on Tuesday, June 16, at 11:00 AM CDT, in which we will break down the following:

  • Why certificate mismanagement causes so much pain at scale
  • How to build real automation that works across your full environment, including internal services and vendor appliances
  • A live demonstration of CertKit showing end-to-end discovery, monitoring, and automated renewal

There will also be time for live Q&A, so bring your questions!

Join Us!

If you’re tired of patching the problem with fragile scripts and assorted reminders, join us to learn about a fully automated solution that can dramatically improve the situation. Register now and don’t miss this opportunity to reduce your TLS certificate management burden and end the need for 2 AM certificate renewal fire drills.

Webinar Details

Webinar: TLS Certificate Automation for Windows Infrastructure
Hosts: Todd Gardner (CertKit) and Richard Hicks (Richard M. Hicks Consulting, Inc.)
Date: Tuesday, June 16
Time: 11:00 AM CDT
Registration: Click here to register!

Recording

If you are unable to attend the live session, be sure to register to receive a link to the recorded session for on-demand viewing.

Leave a comment
by Richard M. Hicks on June 5, 2026  •  Permalink
Posted in Certificate-Based Authentication, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on June 5, 2026

https://directaccess.richardhicks.com/2026/06/05/webinar-certificate-automation-in-practice-a-technical-deep-dive/

Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise

Leave a comment
by Richard M. Hicks on May 18, 2026  •  Permalink
Posted in Always On VPN, Authentication and MFA, Certificate-Based Authentication, Cryptography, PKI, PowerShell, Security Updates, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on May 18, 2026

https://directaccess.richardhicks.com/2026/05/18/microsoft-ad-cs-adds-post-quantum-cryptography-support-with-ml-dsa/

The Case for 6-Day Public TLS Certificates

In February 2025, Let’s Encrypt introduced the option to enroll for public TLS certificates with a 6-day validity period.  This represents a significant shift toward short-lived certificates and aligns with the broader industry trend of reducing certificate lifetimes to improve security. While this may seem aggressive at first glance, organizations that have embraced automation will find that extremely short-lived certificates offer compelling security and operational advantages in some scenarios.

Benefits

Extremely short-lived TLS certificates offer several important security and operational benefits, particularly for organizations that have already embraced automation for certificate lifecycle management. Key advantages include:

  • Minimized Risk of Key Compromise – 6-day certificates dramatically reduce the exposure window of private key compromise events, giving attackers a limited window of opportunity to exploit key access.
  • Automation Validation – Short-lived certificates force organizations to adopt and validate automated enrollment and renewal processes, ensuring that certificate lifecycle management is reliable and resilient.
  • IP Address Support – 6-day TLS certificates from Let’s Encrypt support IP addresses, allowing administrators to secure workloads that do not have entries in DNS.

Use Cases

6-day TLS certificates are well-suited for a range of modern workloads, especially those that benefit from frequent key rotation, automation, and dynamic provisioning. 6-Day TLS certificates are well-suited for the following workloads:

  • High Value Resources – Using 6-day TLS certificates is beneficial for high-security or sensitive workloads where frequent key rotation is desired.
  • Test Labs – High-frequency certificate rotation allows for thorough testing of automation processes to ensure operational reliability of production deployments. Rapid iteration of 6-day TLS certificates allows administrators to identify potential issues and implement changes before long-term certificates expire.
  • Ephemeral Infrastructure – 6-day TLS certificates work well with dynamic workloads such as containers, where environments are rapidly provisioned and destroyed. These hosts might only live for a few hours or days, making short-lived certificates an ideal choice in this scenario.
  • Workload Bootstrapping – 6-day TLS certificates can be used where a certificate is required only to perform initial configuration. For example, an IP-based TLS certificate can be used to configure TLS services, then later migrated to a long-term certificate when DNS is configured and the service is placed into production.

Enterprise Usage

Administrators will find that 6-day public TLS certificates work well with many popular Windows Server workloads. Here are a few examples.

  • Always On VPN – Enterprise secure remote access is a popular target for attackers because the service is exposed to the Internet. Using 6-day TLS certificates ensures frequent key rotation, reducing exposure to key compromise.
  • Remote Desktop Services – Many organizations continue to use Remote Desktop Gateway to provide access to on-premises applications, another workload that is exposed to the Internet. Using 6-day TLS certificates is equally effective in this scenario.

What About DirectAccess?

Although DirectAccess would be another ideal Windows Server workload for 6-day TLS certificates, my testing shows that it does not work. The root cause is that 6-day TLS certificates from Let’s Encrypt do NOT include subject information (the field is blank). Unfortunately, because of the way in which DirectAccess validates this certificate, it requires information in this field. More details can be found here.

https://directaccess.richardhicks.com/2026/03/16/directaccess-iphttps-and-lets-encrypt-6-day-certificates/

Summary

If you are automating certificate enrollment and renewal, it shouldn’t matter if the certificate is valid for 6 days or 60 days. In fact, shorter lifetimes can significantly improve your security posture by minimizing risk and enforcing operational discipline around certificate management. Organizations that invest in automation today will be well-positioned to adopt even shorter certificate lifetimes in the future, while those relying on manual processes will find it increasingly difficult to keep up.

Questions?

Do you have questions about certificate lifecycle automation in your environment? I’m happy to help you validate your approach and address any challenges you’re encountering. Fill out the form below, and I’ll provide you with more information.

Additional Information

Let’s Encrypt Issues First Six-Day Certificate

DirectAccess IP-HTTPS and Let’s Encrypt 6-Day TLS Certificates

The Case for Short-Lived Certificates in the Enterprise

2 Comments
by Richard M. Hicks on May 4, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cryptography, DirectAccess, Microsoft Intune, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , ,

Posted by Richard M. Hicks on May 4, 2026

https://directaccess.richardhicks.com/2026/05/04/the-case-for-6-day-public-tls-certificates/

Webinar: Certificate Automation for Windows Infrastructure

If you manage Windows Server workloads that require public TLS certificates like Always On VPN, DirectAccess, Remote Desktop Gateway, Internet Information Services (IIS), and others, you know that certificate expirations don’t send friendly reminders. Certificates expire quietly. Too often, end users are the ones who sound the alarm—when resources are already unavailable. Of course, this never happens at a convenient time. It’s usually the middle of the night, on the weekend.

Did you miss the webinar? You can view it on demand here!

Current State

Most Windows IT teams are still managing certificates the same way they did years ago, using spreadsheets, calendar reminders, and an assortment of renewal scripts. It usually works… until it suddenly doesn’t.

Free Webinar

I’m pleased to announce that I’ll be joining Todd Gardner from CertKit for a free live webinar on Tuesday, May 26, at 11:00 AM CDT, in which we will break down the following:

  • Why certificate mismanagement causes so much pain at scale
  • How to build real automation that works across your full environment, including internal services and vendor appliances
  • A live demonstration of CertKit showing end-to-end discovery, monitoring, and automated renewal

There will also be time for live Q&A, so bring your questions!

Join Us!

If you’re tired of patching the problem with fragile scripts and assorted reminders, join us to learn about a fully automated solution that can dramatically improve the situation. Register now and don’t miss this opportunity to reduce your TLS certificate management burden and end the need for 2 AM certificate renewal fire drills.

Webinar Details

Webinar: TLS Certificate Automation for Windows Infrastructure
Hosts: Todd Gardner (CertKit) and Richard Hicks (Richard M. Hicks Consulting, Inc.)
Date: Tuesday, May 26
Time: 11:00 AM CDT
Registration: Click here to register!

Recording

If you missed the live event, you can view the on demand recording here!

Leave a comment
by Richard M. Hicks on April 28, 2026  •  Permalink
Posted in Certificate-Based Authentication, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on April 28, 2026

https://directaccess.richardhicks.com/2026/04/28/webinar-certificate-automation-for-windows-infrastructure/

Managed Certificates for Remote Desktop Protocol

The Remote Desktop Protocol (RDP) is arguably the most widely used protocol for Windows remote server administration. RDP uses Transport Layer Security (TLS) for server authentication, data encryption, and integrity. However, the default configuration of TLS for RDP in Windows is less than ideal.

RDP Self-Signed Certificate

By default, RDP uses a self-signed certificate for TLS operations. TLS with self-signed certificates is a bad security practice because they are not validated by a trusted certificate authority (CA), making it impossible for clients to verify the authenticity of the server they are connecting to, which can lead to interception attacks.

Certificate Warning

Most administrators have encountered a warning error when connecting to a remote host via RDP using a self-signed RDP certificate.

“The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed.”

Nmap

You can view the default self-signed certificate with the Nmap utility by running the following command.

nmap.exe -n -p 3389 <hostname> –script ssl-cert

Managed Certificates

A better solution for RDP TLS is to use managed certificates issued by an enterprise Public Key Infrastructure (PKI) such as Microsoft Active Directory Certificate Services (AD CS). AD CS is widely deployed in AD domain environments and can be configured to issue certificates for RDP TLS.

AD CS

To configure AD CS to issue RDP certificates, perform the following steps.

Certificate Template

On an issuing CA or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certificate Templates management console (certtmpl.msc) and perform the following steps.

*My apologies for the list numbering format issues below. Microsoft Word and WordPress can’t seem to agree on the list format. Hopefully, you can figure it out, though. 🙂

  1. Right-click the Workstation Authentication template and choose Duplicate Template.
  2. Select the Compatibility tab.
    1. Select the operating system (OS) version corresponding to the oldest OS hosting the issuing CA role in your environment from the Certification Authority drop-down list.
    1. Select the OS version corresponding to your environment’s oldest supported server or client OS from the Certificate recipient drop-down list.
  3. Select the General tab.
    1. Enter a descriptive name in the Template display name field.
    1. Select an appropriate validity period for your environment. The best practice is to limit the validity period to one year or less.
  4. Select the Cryptography tab.
    1. From the Provider Category drop-down list, choose Key Storage Provider.
    1. From the Algorithm name drop-down list, choose RSA.
    1. In the Minimum key size field, enter 2048.
    1. From the Request hash drop-down list, choose SHA256.
  5. Select the Subject Name tab.
    1. From the Subject name format drop-down list, select DNS name.
    1. Ensure that DNS name is also checked in the subject alternate name section.
  6. Select the Extensions tab.
    1. Click on Application Policies.
    1. Click Edit.
    1. Select Client Authentication.
    1. Click Remove.
    1. Click Add.
    1. Click New.
    1. Enter Remote Desktop Authentication in the Name field.
    1. Enter 1.3.6.1.4.1.311.54.1.2 in the Object identifier field.
    1. Click Ok.
    1. Select Remote Desktop Authentication.
    1. Click Ok.
  7. Select the Security tab.
    1. Click Domain Computers.
    1. Grant the Read and Enroll permissions.
  8. Click Ok.

Next, open the Certification Authority management console (certsrv.msc) and follow the steps below to publish the certificate.

  1. Expand the CA.
  2. Right-click Certificate Templates and choose New > Certificate Template to Issue.
  3. Select the Remote Desktop Authentication certificate template.
  4. Click Ok.

Group Policy

Next, on a domain controller or a workstation with the RSAT tools installed, open the Group Policy Management console (gmpc.msc) and perform the following steps to create a new GPO to enroll domain computers for the Remote Desktop Authentication certificate

  1. Right-click Group Policy Objects and choose New.
  2. Enter a descriptive name for the GPO in the Name field.
  3. Click Ok.
  4. Right-click the GPO and choose Edit.
  5. Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
  6. Double-click Server authentication certificate template.
  7. Select Enabled.
  8. Enter the name of the Remote Desktop Authentication certificate template in the Certificate Template Name field. Note: Be sure to enter the template name, not the template display name!
  9. Click Ok.

Once complete, link the GPO to the domain or OU to target the servers and workstations to which you wish to deploy the RDP certificate.

Validate Certificate

After updating group policy on a target resource, you’ll find that Nmap now shows the enterprise PKI-issued certificate used for RDP connections.

Additional Information

Understanding the Remote Desktop Protocol (RDP)

4 Comments
by Richard M. Hicks on February 20, 2025  •  Permalink
Posted in Authentication and MFA, Microsoft Intune, PKI, TLS, Windows Server
Tagged , , , , , , ,

Posted by Richard M. Hicks on February 20, 2025

https://directaccess.richardhicks.com/2025/02/20/managed-certificates-for-remote-desktop-protocol/

DirectAccess Manage Out with ISATAP and NLB Clustering

DirectAccess Manage Out with ISATAP and NLB ClusteringDirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.

ISATAP Supportability

According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.

“Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).

ISATAP Configuration

To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.

DirectAccess Manage Out with ISATAP and NLB Clustering

Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.

Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:

Set-NetIsatapConfiguration -State Enabled -Router [ISATAP FQDN] -PassThru

DirectAccess Manage Out with ISATAP and NLB Clustering

Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.

DirectAccess Manage Out with ISATAP and NLB Clustering

Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.

DirectAccess Manage Out with ISATAP and NLB Clustering

Finally, verify network connectivity from the manage out host to the remote DirectAccess client.

Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.

Group Policy Deployment

If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.

DirectAccess Client Firewall Configuration

Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.

ISATAP Manage Out for Multisite and ELB

The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.

Summary

Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.

Additional Information

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

Contact Me

Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.

← Back

Thank you for your response. ✨

3 Comments
by Richard M. Hicks on December 14, 2017  •  Permalink
Posted in DirectAccess, DNS and NRPT, IPv6, Load Balancing, Windows Server
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 14, 2017

https://directaccess.richardhicks.com/2017/12/14/directaccess-manage-out-with-isatap-and-nlb-clustering/

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

The seamless and transparent nature of DirectAccess makes it wonderfully easy to use. In most cases, it requires no user interaction at all to access internal corporate resources while away from the office. This enables users to be more productive. At the same time, it offers important connectivity benefits for IT administrators and systems management engineers as well.

Always Managed

DirectAccess Manage Out and System Center Configuration Manager (SCCM)DirectAccess clients are automatically connected to the corporate network any time they have a working Internet connection. Having consistent corporate network connectivity means they receive Active Directory group policy updates on a regular basis, just as on-premises systems do. Importantly, they check in with internal management systems such as System Center Configuration Manager (SCCM) and Windows Server Update Services (WSUS) servers, enabling them to receive updates in a timely manner. Thus, DirectAccess clients are better managed, allowing administrators to more effectively maintain the configuration state and security posture for all their managed systems, including those that are predominantly field-based. This is especially crucial considering the prevalence WannaCry, Cryptolocker, and a variety of other types of ransomware.

DirectAccess Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)When manage out is configured with DirectAccess, hosts on the internal network can initiate connections outbound to remote connected DirectAccess clients. SCCM Remote Control and Remote Desktop Connection (RDC) are commonly used to remotely connect to systems for troubleshooting and support. With DirectAccess manage out enabled, these and other popular administrative tools such as VNC, Windows Remote Assistance, and PowerShell remoting can also be used to manage remote DirectAccess clients in the field. In addition, enabling manage out allows for the proactive installation of agents and other software on remote clients, such as the SCCM and System Center Operation Manager (SCOM) agents, third-party management agents, antivirus and antimalware software, and more. A user does not have to be logged on to their machine for manage out to work.

IPv6

DirectAccess manage out requires that connections initiated by machines on the internal network to remote-connected DirectAccess clients must be made using IPv6. This is because DirectAccess clients use IPv6 exclusively to connect to the DirectAccess server. To enable connectivity over the public IPv4 Internet, clients use IPv6 transition technologies (6to4, Teredo, IP-HTTPS), and IPv6 translation components on the server (DNS64 and NAT64) enable clients to communicate with internal IPv4 resources. However, DNS64 and NAT64 only translate IPv6 to IPv4 inbound. They do not work in reverse.

Native or Transition?

It is recommended that IPv6 be deployed on the internal network to enable DirectAccess manage out. This is not a trivial task, and many organizations can’t justify the deployment for just this one specific use case. As an alternative, IPv6 can be configured with an IPv6 transition technology, specifically the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). ISATAP functions as an IPv6 overlay network, allowing internal hosts to obtain IPv6 addresses and routing information from an ISATAP router to support manage out for DirectAccess clients.

ISATAP

When DirectAccess is installed, the server is automatically configured as an ISATAP router. Guidance for configuring ISATAP clients can be found here. Using ISATAP can be an effective approach to enabling DirectAccess manage out for SCCM when native IPv6 is not available, but it is not without its drawbacks.

• Using the DirectAccess server for ISATAP is only supported with single server DirectAccess deployments.
• Using the DirectAccess server for ISATAP does work when using Network Load Balancing (NLB) with some additional configuration, but it is not supported.
• Using the DirectAccess server for ISATAP does not work when an external load balancer is used, or if multisite is enabled.

ISATAP with Load Balancing and Multisite

It is technically possible to enable DirectAccess manage out for SCCM using ISATAP in load-balanced and multisite DirectAccess deployments, however. It involves deploying a separate ISATAP router and some custom configuration, but once in place it works perfectly. I offer this service to my customers as part of a consulting engagement. If you’re interested in restoring DirectAccess manage out functionality to support SCCM remote control, RDC, or VNC in load-balanced or multisite DirectAccess deployments, fill out the form below and I’ll provide you with more information.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments
DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
Video: Windows 10 DirectAccess in action (includes manage out demonstration)

← Back

Thank you for your response. ✨

2 Comments
by Richard M. Hicks on June 12, 2017  •  Permalink
Posted in Consulting Services, DirectAccess, IPv6, Load Balancing, PowerShell, Windows Server
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 12, 2017

https://directaccess.richardhicks.com/2017/06/12/directaccess-manage-out-and-system-center-configuration-manager-sccm/

DirectAccess and Windows 10 in Action

DirectAccess and Windows 10 in ActionRecently I recorded a short video to outline some of the benefits of using Windows 10 and DirectAccess. The video highlights common uses cases and includes a working demonstration of DirectAccess and Windows 10, both from the user’s and the administrator’s perspective.

The video shows how users transparently connect to the network and seamlessly access corporate resources over the DirectAccess connection. It also shows how administrators can leverage existing system management tools such as the Computer Management MMC, PowerShell remoting, and the Remote Desktop Protocol (RDP) to manage remote connected Windows 10 DirectAccess clients.

If you have any questions about implementing DirectAccess, integrating Windows 10 clients, or enabling outbound management, click here.

5 Comments
by Richard M. Hicks on May 2, 2016  •  Permalink
Posted in DirectAccess, PowerShell, Training and Events, Windows Server
Tagged , , , , , ,

Posted by Richard M. Hicks on May 2, 2016

https://directaccess.richardhicks.com/2016/05/02/directaccess-and-windows-10-in-action/

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

21 Comments
by Richard M. Hicks on April 13, 2015  •  Permalink
Posted in DirectAccess, IPv6, Windows Server
Tagged , , , , , , , , , , ,

Posted by Richard M. Hicks on April 13, 2015

https://directaccess.richardhicks.com/2015/04/13/directaccess-client-firewall-rule-configuration-for-isatap-manage-out/

« Older Posts