Configuring SCCM with UAG DirectAccess (Part 1)

If you would like to be read the next part in this article series please go to Configuring SCCM with UAG DirectAccess (Part 2).

Introduction

I’ve written a lot on this site about DirectAccess, the new remote access technology that was introduced with Windows 2008 R2 and Windows 7. DirectAccess gives you a way to connect a system seamlessly and securely to your corporate network from anywhere in the world. We’ve talked before about how Forefront Unified Access Gateway (UAG) 2010 can extend the benefits of DirectAccess across your infrastructure, enhancing scalability and simplifying deployment and management.

This time, we’re going to discuss how System Center Configuration Manager (SCCM) can work with DirectAccess clients and how you can remotely manage those DirectAccess clients that are located outside your local network. This two part article is going to start with a review of how DirectAccess works, then show you how to configure a SCCM site with UAG DA. This is an option that you can use in place of SCCM native mode configuration. Since DA makes clients connecting from outside appear as if they were on your LAN, it makes it much easier to manage those clients with SCCM.

UAG DirectAccess: What’s it all about

First of all, let’s take a look at DirectAccess and how it works, so that you’ll have a basic understanding of the foundation of the technology when we get to the “meat” of the matter: deploying it for use with SCCM. This will also aid you in understanding how to troubleshoot problems with your SCCM management that could be related to DirectAccess.

DirectAccess uses IPv6 for its connectivity but access to the IPv6 Internet is somewhat limited at this time. That means DirectAccess clients may need to use IPv6 transition technologies to transport their IPv6 messages over the IPv4 Internet. DirectAccess clients can use any of the popular transition technologies to accomplish this.

Remember that DirectAccess uses IPsec for protecting the integrity and confidentiality of data. IPsec is very tightly integrated with IPv6, so this allows the Windows Firewall with Advanced Security rules to control when and how the IP traffic should be protected.

UAG DirectAccess also extends the benefits of DirectAccess by enabling NAP enforcement and quarantine of remote clients, as well as access to IPv4 only resources on the corporate network. It does this by acting as NAT 64 and DNS 64 gateway.

For more information about the advantages of using UAG DirectAccess, have a look at the UAG DirectAccess website or see some of my previous articles on this site, such as this one called UAG DirectAccess the Easy way.

Going back to the most popular IPv6 transition techniques that are commonly used in UAG DirectAccess, we first need to distinguish between those that are used on the Internet and those that are used on the local network.

IPv6 transition technologies used on the Internet include 6to4, Teredo and IP-HTTPS. Those that are commonly used on the intranet include ISATAP and NAT64/DNS64. Let’s delve a little deeper into the details of each of these technologies. First, we’ll look at the ones used on the Internet.

6to4

6to4 is the most common IPv6 over IPv4 tunneling protocol; Encapsulates IPv6 packets inside IPv4 packets for transmission over an IPv4 network using 6in4, which is defined in RFC 4213. DirectAccess clients use 6to4 when they have a public IPv4 address assigned to them.

The infrastructure requirements for 6to4 are as follows:

1. The DirectAccess client tunnel endpoint must have a public IPv4 address
2. Relay router: connects to an IPv4 network and an IPv6 network.

Here is the address format for 6to4:

Bits 0-15:              2001

Bits 16-47:           IPv4 address (eg: IPv4=60.63.47.187->3C3F:2FBB)

Bits 97-127:         arbitrarily chosen by the router

Teredo

When the DirectAccess client is behind one or more Network Address Translation (NAT) devices, it will attempt to use Teredo, which encapsulates IPv6 packets within IPv4 UDP datagrams, and most NAT devices can forward properly these datagrams.

The infrastructure requirements for Teredo are as follows:

• Teredo server: This is a well-known host that is used for the initial configuration of a Teredo tunnel. (This server is used only to specify the prefix, so it can serve an unlimited number of clients).
• Teredo relay: This machine serves as the remote end of a Teredo tunnel.
• Teredo host-relay: This is a Teredo relay, the range of service of which is limited to only the host on which it runs.

Here is the address format for Teredo:

Bits 0-31:              2002:0

Bits 32-63:           primary IPv4 address of the Teredo server that is used.

Bits 64-79:           flags

Bits 80-95:           the port number that is mapped by the NAT to the Teredo client with all bits inverted

Bits 96-127:         is the public IPv4 address of the NAT with all bits inverted. (eg: IPv4 = 60.63.47.187->3C3F:2FBB->C3C0:D044 (FFFF-))

Note that by default all Windows-based Teredo clients are configured to resolve the name teredo.ipv6.microsoft.com to determine the IPv4 address of the Microsoft Teredo server on the Internet. If you deploy your own Teredo server, you will have to configure your client computers with either the first IPv4 address of your Teredo server or a DNS name that resolves to that same IPv4 address. You can use the netsh interface teredo set state server=NameOrFirstIPv4Address command to configure your hosts with the Teredo server. Another option is that for computers that are running Windows 7 and/or Windows Server 2008 R2, you can use the Teredo Server Name Group Policy setting. This is the method that is used for UAG DirectAccess client and server configuration. You’ll find it in the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies node of the Group Policy object for DirectAccess clients.

IP-HTTPS

IP-HTTPS is a new protocol that is included with Windows 7 and Windows Server 2008 R2 and it allows hosts to establish a connection through a Web proxy or a port-limiting firewall by tunneling IPv6 packets inside an IPv4-based secure HTTPS session. IP-HTTS is used only when the client is not able to connect to the server using any of the other standard IPv6 connectivity protocols such as native IPv6, Teredo, or 6to4.

Here are the infrastructure requirements for IP-HTTPS:

• Win 7 or
• Windows 2008 R2.

You don’t have to explicitly enable IP-HTTPS. If 6to4 or Teredo connectivity is not available, your Windows 7 DirectAccess clients will automatically attempt to connect using IP-HTTPS. If you want to force the clients to use IP-HTTPS, you can use netsh to disable Teredo by using the following command: netsh interface teredo set state disable.

If your IP-HTTPS solution is working properly, your DirectAccess client will then switch over to IP-HTTPS. You can verify that this has happened by using the following command: netsh interface httpstunnel show interfaces.

If everything is indeed working correctly, you should see something like the following:

————————————————————
Role : client
URL : https://da.companyabc.com:443/IPHTTPS
Last Error Code : 0x0
Interface Status : IPHTTPS interface active
————————————————————-

If you want to re-enable Teredo, you would use the following command: netsh interface teredo set state default. Once this has been executed, your Teredo interface will be active again and things will work as they did before.

Now let’s move on to the IPv6 transition technologies that are commonly used on the corporate intranet.

ISATAP

ISATAP is an IPv6 transition technology that enables the transmission of IPv6 packets between dual-stack nodes on top of an IPv4 network infrastructure. Dual-stack implementations are also called hybrid stacks. The purpose is to enable programmers to write code that will work on both IPv4 and IPv6. You can read more about dual-stack hosts in RFC 4213.

Here is the address format for ISATAP:

Bits 0-95:              fe80:0000:0000:0000:0000:5efe

Bits 96-127:         IPv4 address (eg: IPv4=60.63.47.187->3C3F:2FBB)

In order to enable ISATAP, you will need to add a Host (A) record for ISATAP in DNS. The client will then automatically discover the ISATAP router and it will assign itself an ISATAP IPv6 address, and use that server as its ISATAP router.

NAT64/DNS64:

NAT64/DNS64 is an IPv6/IPv4 protocol translation technology that enables the DirectAccess IPv6 client to access IPv4 only resources. Because the NAT64 component does not support “reverse NAT”, IPv4 only resources on the intranet are not able to make connections to DirectAccess clients.

Here’s how it works: An IPv6 prefix (either well-known or network-specific) is dedicated to mapped IPv4 addresses. DNS64 converts A records into AAAA records using NAT64 address and the NAT64 router advertises the NAT64 prefix into the IPv6 network to direct traffic toward IPv4 servers.

The network-specific prefix can be any /32, /40, /48, /56, /64 or /96 prefix.

The welll known prefix is: 64:FF9B::/96

Behavior of DirectAccess Clients

Let’s take a quick look at how the DA clients connect to resources on the local corporate network. First of all, remember that two tunnels are created between the DirectAccess client and UAG DirectAccess server: the Infrastructure Tunnel and the Intranet Tunnel.

The Infrastructure Tunnel is established before the user logs on to the client computer. It uses a machine certificate along with the computer account (NTLMv2) to authenticate the client with the UAG DirectAccess server.

The intranet tunnel requires machine certificate as well as user Kerberos authentication. It is established after the user logs onto the DirectAccess client computer. A server that provides services to a DirectAccess client when no user is logged on (such as a DNS, AD or SCCM Management Point server) will need to use the infrastructure tunnel, and it must be included in the list of infrastructure servers.

The DirectAccess client can use IPsec transport mode to connect to servers on the intranet in end-to-end security scenarios.

Now let’s look at how DA Clients determine whether they are on the intranet or the Internet. The Network Location Server (NLS) is used to determine whether the DirectAccess client is connected to the intranet. Here’s how that works: If the DirectAccess client is able to establish an HTTPS session with the Network Location Server (NLS) and receive a 200 response back, then the DirectAccess client will turn off the Name Resolution Policy Table and use the DNS server configured on the client’s NIC, instead of the DNS server entries in the Name Resolution Policy Table. UAG will set a group policy to define a connection rule named “Exempt NLA”. The “Exempt NLA” rule is to prevent the client from communicating with the Network Location Server when it’s on the Internet.

Summary

Now that you understand the details of how the DA clients are connecting, you’re ready for Part 2, where we will go through the steps of configuring SCCM to work with UAG DA. See you there!