One of the more common questions regarding the UAG DirectAccess server relates to certificate requirements. The reason for this is that PKI is an important component of a DirectAccess solution. There are basically three places where you need to plan for certificate deployment in your UAG DirectAccess solution.
These three general areas include:
- Computer certificates
- Network Location Server certificates
- IP-HTTPS listener certificates
Computer Certificates
Computer certificates are used for client and server authentication on the UAG DirectAccess server and the DirectAccess clients. These certificates are usually generated by your private PKI using your Microsoft Certificate Server and deployed using autoenrollment. The computer certificates allow the clients to prove their identity to the UAG DirectAccess server and allow the UAG DirectAccess server to prove its identity to the DirectAccess clients. The certificates are required for authenticating both the intranet and infrastructure tunnels.
Network Location Server Web Site Certificates
A Network Location Server (NLS) is used by the DirectAccess client to determine if the DirectAccess client is on the intranet. If the DirectAccess client can create an SSL session with a Network Location Server on the intranet, then it knows that it’s on the intranet and the DirectAccess turns off the Name Resolution Policy Table and uses the DNS server configured on the network interface, which is typically assigned to the client over DHCP. In order for the Network Location Server to enable SSL connects to itself, it needs a web site certificate bound to the web site hosted by the Network Location Server. There are no special requirements for the Network Location Server – it can be any SSL site – there is no specific or special content required.
IP-HTTPS Certificates
IP-HTTPS is an IPv6 transition protocol that allows the DirectAccess client to connect to the UAG DirectAccess server over the IPv4 Internet. IP-HTTPS encapsulates the IPv6 messages in an IPv4 header and then wraps that up in an HTTP header and then encrypts it with SSL. As you can imagine, there’s a lot of overhead in the protocol, but it does allow the DirectAccess client to connect to the UAG DirectAccess server even when the client is located behind a port restricted firewall or even when the DirectAccess client is located behind a web proxy server. In order to create an IP-HTTPS listener on the UAG DirectAccess server, you need to acquire a certificate for the listener. In general, you should use a commercial certificate for this, since the DirectAccess client needs to be able to check the CRL for the IP-HTTPS certificate and commercial certificate providers have already built out a highly available CRL access infrastructure.
That’s about it. The certificate requirements for UAG DirectAccess are not onerous or complex. There are no “special” certificates required, no special SAN entries, or any other “off-label” requirements. Most organizations will generate their own computer certificates and use autoenrollment, and most firms are going to create their own certificates for the Network Location Server. You could even use private certificates for the IP-HTTPS listener if you want, but you would then need to publish your private CRL. That’s not too difficult, but you can make life easier using a commercial certificate, if for no other reason than that you don’t need to create your own high availability solution for the CRL.
HTH,
Deb
DEBRA LITTLEJOHN SHINDER
MVP (Enterprise Security)
“MS SECURITY”
[email protected]