Share via

Design Your PKI for DirectAccess

  • Article

Applies To: Windows 7, Windows Server 2008 R2

Important

This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (https://go.microsoft.com/fwlink/?LinkId=179988).

A DirectAccess deployment needs a public key infrastructure (PKI) to issue certificates to DirectAccess clients, the DirectAccess server, selected servers, and the network location server.

Autoenrollment for computer certificates

The DirectAccess Setup Wizard allows you to configure the full intranet access and selected server access models that by default use certificates for Internet Protocol security (IPsec) peer authentication. The easiest way to get certificates installed on both DirectAccess clients and servers is to configure autoenrollment for computer certificates. For example, autoenrollment at the domain level ensures that all domain members obtain a computer certificate from an enterprise certification authority (CA).

For more information, see Configure Computer Certificate Autoenrollment in the DirectAccess Deployment Guide.

Note

The DirectAccess test lab (https://go.microsoft.com/fwlink/?Linkid=150613) uses autoenrollment of computer certificates to simplify computer certificate enrollment for members of the corp.contoso.com domain.

Manual enrollment for network location server and IP-HTTPS certificates

You also need to manually enroll the following certificates:

  • An additional certificate on the DirectAccess server for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) authentication

  • An additional certificate for the network location server for HTTPS authentication

The IP-HTTPS certificate for the DirectAccess server must have the following properties:

  • In the Subject field, either an Internet Protocol version 4 (IPv4) address of the Internet interface of the DirectAccess server or the fully qualified domain name (FQDN) corresponding to the Internet name of the DirectAccess server, which must be resolvable with Internet-based DNS servers.

  • For the Enhanced Key Usage field, the Server Authentication object identifier (OID).

  • For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is accessible by DirectAccess clients that are connected to the Internet.

The HTTPS certificate for the network location server must have the following properties:

  • In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the network location server or the FQDN of the network location uniform resource locator (URL).

  • For the Enhanced Key Usage field, the Server Authentication OID.

  • For the CRL Distribution Points field, a CRL distribution point that is accessible by DirectAccess clients that are connected to the intranet.

If the DirectAccess server is the network location server, you need an additional certificate for HTTPS authentication. You cannot use the IP-HTTPS certificate for the network location server HTTPS certificate. You should configure both certificates with friendly names that indicate their purpose so that they are easier to select in the DirectAccess Setup Wizard.

For more information, see the following topics in the DirectAccess Deployment Guide:

Note

The DirectAccess test lab (https://go.microsoft.com/fwlink/?Linkid=150613) uses manually enrolled certificates on the network location server and the DirectAccess server.

Certificate revocation checking and CRL distribution points

The following types of connections require a certificate revocation check:

  • The IP-HTTPS connection between the DirectAccess client and the DirectAccess server.

    If the certificate revocation check fails, DirectAccess clients cannot make IP-HTTPS-based connections to a DirectAccess server. Therefore, an Internet-based CRL distribution point location must be present in the IP-HTTPS certificate and accessible by DirectAccess clients that are connected to the Internet.

  • The HTTPS-based connection between the DirectAccess client and the network location server.

    If the certificate revocation check fails, DirectAccess clients cannot successfully access an HTTPS-based URL on the network location server. Therefore, an intranet-based CRL distribution point location must be present in the network location server certificate and be accessible by DirectAccess clients that are connected to the intranet, even when there are DirectAccess rules in the NRPT.

  • The IPsec tunnels between the DirectAccess client and the DirectAccess server.

    See “Enabling strong CRL checking for IPsec authentication” in this topic.

For both Internet and intranet-based CRLs, the CRL distribution points must be highly available. CRL distribution points can be accessed through Web servers using an HTTP-based URL, such as https://crl.corp.contoso.com/crld/corp-DC1-CA.crl.

Note

Checking of CRL distribution points based on a universal naming convention (UNC) path, such as \crl.corp.contoso.com\crld\corp-DC1-CA.crl, is disabled by default in Windows 7 and Windows Server 2008 R2. For information about how to enable checking of UNC-based CRL distribution points, see the following KnowledgeBase article (https://go.microsoft.com/fwlink/?LinkId=196867). UNC-based CRL distribution points can be used only for intranet CRL locations. For the Internet location of the CRL distribution point, you should always use an HTTP-based URL. DirectAccess clients that use IP-HTTPS to send IPv6 packets across the IPv4 Internet check the Internet CRL distribution point. IP-HTTPS-based DirectAccess clients can be located behind proxy servers that do not forward file and printer sharing traffic.

For more information, see Configure a CRL Distribution Point for Certificates in the DirectAccess Deployment Guide.

Note

If your intranet CRL distribution points are only reachable over IPv6, you must configure a Windows Firewall with Advanced Security connection security rule to exempt IPsec protection from the IPv6 address space of your intranet to the IPv6 addresses of your CRL distribution points.

Note

For ease of configuration, the DirectAccess test lab (https://go.microsoft.com/fwlink/?Linkid=150613) uses the URL https://crl.contoso.com/crld/corp-DC1-CA.crl for both Internet and intranet CRL distribution points. For the intranet, an A record in the intranet DNS resolves the name crl.contoso.com to the intranet IPv4 address of EDGE1, the DirectAccess server. For the Internet, an A record in the Internet DNS resolves the name crl.contoso.com to an Internet IPv4 address of EDGE1.

Using a commercial CA for the IP-HTTPS certificate

You can also use a certificate issued from a commercial CA for the IP-HTTPS certificate installed on the DirectAccess server. With a commercial CA certificate, you do not have to create a highly-available Internet CRL distribution point. This is already set up and maintained by the commercial CA vendor. If you use a commercial CA certificate, you must also ensure that the root CA certificate for the IP-HTTPS certificate is installed in the Trusted Root Certification Authorities folder in the computer certificate store of your DirectAccess clients.

Enabling strong CRL checking for IPsec authentication

By default, the DirectAccess server and DirectAccess clients uses weak CRL checking when performing certificate-based IPsec peer authentication. With weak CRL checking, certificate revocation checking fails only if the validating computer confirms that the certificate has been revoked in the CRL. Revoking computer certificates is one way of blocking DirectAccess for specific DirectAccess clients. A simpler and preferred method is to disable the computer account in Active Directory. This method immediately prevents DirectAccess connections, such as when a laptop computer is lost or stolen, and does not have the delay associated with propagating CRL updates to CRL distribution points.

For an additional level of protection, you can configure strong CRL checking, in which certificate revocation checking fails if the validating computer confirms that the certificate has been revoked or for any error encountered during certificate revocation checking, including the inability to access the CRL distribution point. For more information, see Configure Strong Certificate Revocation Checking for IPsec Authentication in the DirectAccess Deployment Guide.

Note

If you enable strong CRL checking and the DirectAccess server cannot reach the CRL distribution point, certificate-based IPsec authentication for all DirectAccess connections will fail.

Note

If you are using Network Access Protection (NAP) with DirectAccess and you enable strong CRL checking, certificate-based IPsec authentication for all DirectAccess connections will fail. Health certificates do not contain CRL distribution points because their lifetime is on the order of hours, instead of years for computer certificates.

Smart cards for additional authorization

To use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment and a smart card infrastructure. After your smart card deployment has been completed, you enable smart card authorization on the Connectivity page of Step 2 of the DirectAccess Setup Wizard.

Note

You should design your PKI to replicate the entire smart card certificate chain to the current user certificate store in a timely manner. If the PKI is slow in replicating the certificate chain, users will obtain a smart card certificate and leave the intranet, but be unable to use smart card authorization. To correct this condition, they might have to return to the intranet and logon with their smart card credentials to force the PKI to install the entire certificate chain in the local user’s certificate store.

Using Suite B certificates for DirectAccess

Suite B is a set of cryptographic algorithms defined by the National Security Agency (NSA). You can use Suite B-based certificates for DirectAccess by deploying a PKI that uses Suite B cryptographic algorithms. For information about deploying a Windows-based PKI that supports Suite B and issues Suite B-based certificates, see Suite B PKI in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=190434).

Important

Appendix A of this white paper describes setting the IKEFlags registry value to 0x40 to disable the use of the Authenticating IP (AuthIP). DirectAccess cannot function without AuthIP. Therefore, you must not set this registry value in a DirectAccess deployment. AuthIP in Windows 7 and Windows Server 2008 R2 supports the use of Diffie Hellman (DH) for key exchange for AuthIP, which you enable with the netsh advfirewall set global mainmode mmforcedh yes command.