All posts in category IP-HTTPS

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Introduction

When preparing a DirectAccess server, an SSL certificate is required for the IP-HTTPS IPv6 transition technology. This certificate is often issued by a public Certification Authority (CA), but it can also be issued an organization’s internal Public Key Infrastructure (PKI).

SSL Certificate

Commonly an SSL certificate is issued for a single hostname, or subject. As long as the hostname matches the subject, everything works fine.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Multi-SAN SSL Certificate

To ease the management burden of using multiple certificates, or reduce the expense associated with using a wildcard certificate, organizations can request a multi-SAN (Subject Alternative Name) certificate, which matches more than one subject. The additional subjects are included in the Subject Alternative Name field on the SSL certificate.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS
A single multi-SAN certificate can be installed on multiple hosts and will work without issue as long as the hostname matches one of the SAN entries.

DirectAccess and Multi-SAN Certificates

When implementing DirectAccess in a multisite configuration, each entry point in the organization will have a unique public hostname. Instinctively, using a multi-SAN SSL certificate in this scenario would seem ideal.

Unfortunately, support for multi-SAN SSL certificates with DirectAccess is limited. To use a multi-SAN certificate for DirectAccess IP-HTTPS, the public hostname must match the name listed in the Subject field. In the example above, the subject is da.richardhicks.net, with SAN entries for da-west.richardhicks.net and da-east.richardhicks.net.

In this scenario, only the public name da.richardhicks.net is supported for use with DirectAccess. It will not work for any of the SAN entries. For example, attempting to configure DirectAccess to use this certificate with the public hostname da-west.richardhicks.net will fail with the following error message.

The subject name of certificate CN=[certificate subject name] is invalid.
Select a certificate with a valid subject name.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Attempting to work around this issue by using the Set-DAServer PowerShell cmdlet also fails to recognize the SSL certificate correctly.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Summary

Using a multi-SAN SSL certificate for the DirectAccess IP-HTTPS IPv6 transition technology is only supported when the public hostname matches the subject name of the certificate. Configuring DirectAccess with a public hostname listed in the SAN list is not supported. For multisite DirectAccess deployments, individual certificates must be issued for each entry point. Alternatively, a wildcard certificate can be used.

9 Comments
by Richard M. Hicks on March 28, 2016  •  Permalink
Posted in DirectAccess, IP-HTTPS, IPv6, IPv6 Transition, Remote Access, SSL and TLS, Windows 8, Windows 8.1, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 28, 2016

https://directaccess.richardhicks.com/2016/03/28/directaccess-and-multi-san-ssl-certificates-for-ip-https/

DirectAccess IP-HTTPS Discovery Script for Nmap

DirectAccess IP-HTTPS Discovery Script for NmapWhen troubleshooting DirectAccess connectivity issues, the popular Nmap network mapping and discovery tool is an invaluable resource for verifying the communication path to the DirectAccess server from outside the network. However, just verifying that ports are open and listening often isn’t sufficient. In the case of IP-HTTPS, for example, the tried and true method of using telnet to verify that the port is open might be misleading. For instance, telnet might indicate that TCP port 443 is open and responding, but DirectAccess connectivity can still fail. This often happens as a result of a network configuration error that allows another network device other than the DirectAccess server to respond to HTTPS requests, which results in a false positive.

In an effort to conclusively determine that the DirectAccess server is responding, I’ve often relied on the SSL Labs Server Test site. Here I will enter the DirectAccess server’s public hostname and run the test, and from the results I can easily determine if indeed the DirectAccess server is responding by verifying that the HTTP server signature is Microsoft-HTTPAPI/2.0.

DirectAccess IP-HTTPS Discovery Script for NMAP

This usually works well, but it takes a few minutes to run the test, and there are a few scenarios in which it doesn’t work. For example, I might be working with a customer to perform some initial testing by using a local HOSTS file entry for the public name before the DNS record has been created. Also, if the SSL certificate on the DirectAccess server uses an IP address instead of a hostname (not recommended, but it is supported!) the SSL Labs server test won’t work.

Fortunately, the latest release Nmap (v7.00) now includes a script that enables the detection of Microsoft DirectAccess responding on TCP port 443. With the IP-HTTPS discovery script, it is now possible to determine not only if the port is open, but if the DirectAccess server is actually the service responding. The syntax for conducting a port scan using the IP-HTTPS discovery script for NMAP is as follows:

nmap.exe –n –Pn –p443 [directaccess_public_fqdn] –script [path_to_nmap_iphttps_discovery_script]

Here’s an example:

nmap.exe –n –Pn –p443 da.richardhicks.net –script c:\tools\nmap\scripts\ip-https-discover.nse

DirectAccess IP-HTTPS Discovery Script for NMAP

Now it is possible, using just Nmap, to not only determine if the IP-HTTPS communication path is functioning, but to definitively determine that the DirectAccess server is the device responding.

Happy troubleshooting!

7 Comments
by Richard M. Hicks on November 30, 2015  •  Permalink
Posted in DirectAccess, Encryption, IP-HTTPS, IPv6, IPv6 Transition, Remote Access, SSL and TLS, Windows Server 2012 R2
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 30, 2015

https://directaccess.richardhicks.com/2015/11/30/directaccess-ip-https-discovery-script-for-nmap/

3 Important Things You Need to Know about Windows 10 and DirectAccess

DirectAccess and Windows 10 - Better TogetherDirectAccess has been with us for quite some time know, having been originally introduced with Windows Server 2008 R2, later enhanced with Forefront Unified Access Gateway (UAG) 2010, and finally integrated in to the base operating system in Windows Server 2012 R2. Client support for DirectAccess begins with Windows 7 (Enterprise or Ultimate), and also includes Windows 8.x (Enterprise) and Windows 10 (Enterprise or Education).

Although Windows 7 clients are supported for DirectAccess, Windows 10 is highly preferred. Here are three important things you need to know about using Windows 10 with DirectAccess.

  1. Windows 10 Provides Improved Performance and Scalability – Windows 10 includes support for null encryption when using the IP-HTTPS IPv6 transition protocol. This eliminates the needless double-encryption performed by Windows 7 clients, and dramatically reduces the protocol overhead for clients connecting behind port-restricted firewalls. DirectAccess servers can support many more concurrent IP-HTTPS sessions with Windows 10, and it has the added benefit of making the more secure perimeter/DMZ deployment behind an edge security device performing NAT much more attractive.
  2. Windows 10 Supports Geographic Redundancy – Windows 10 includes full support for DirectAccess multisite deployments. Where Windows 7 clients had to be assigned to a single entry point, Windows 10 clients are aware of all entry points in the organization. They are able to automatically select the nearest entry point on startup, and transparently failover to another site if the current site becomes unavailable.
  3. Windows 10 Features an Enhanced Management Experience – From a troubleshooting and support perspective, Windows 10 makes things much easier. The DirectAccess connectivity assistant, an optional component for Windows 7, is now fully integrated with the Windows 10 UI. PowerShell is greatly improved and now includes many native DirectAccess configuration and troubleshooting commands.

As you can see, there are a number of significant advantages for using Windows 10 with DirectAccess. Windows 10 now supports all of the enterprise features of DirectAccess, including geographic redundancy and performance and scalability improvements. Windows 10 is also easier to troubleshoot and manage. If you’re still supporting Windows 7, DirectAccess in Windows Server 2012 R2 can certainly support them. However, without a doubt the best experience, both from an administrator’s and the end user’s perspective, is with Windows 10. Just one more reason to begin planning your migration to Windows 10 with DirectAccess today!

Need assistance with implementing  DirectAccess with Windows 10? I can help! More details here.

16 Comments
by Richard M. Hicks on November 11, 2015  •  Permalink
Posted in Consulting Services, DirectAccess, Enterprise, Forefront UAG 2010, High Availability, IP-HTTPS, IPv6, IPv6 Transition, PowerShell, Professional Services, Remote Access, Security, SSL and TLS, Windows 10, Windows Server 2012 R2
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 11, 2015

https://directaccess.richardhicks.com/2015/11/11/3-important-things-you-need-to-know-about-windows-10-and-directaccess/

« Older Posts
Newer Posts »