I Am Digerati

Continuing on with my post for DirectAccess, this one will be dedicated on how DA works under the hood.

DA is implemented on standards based technologies. Both IPSec and IPv6 are used. Let's review why these were chosen.

Technologies

IPSec is used as the tunneling and security protocol suite, and IPv6 is used for connectivity. Client's need to have a globally routable IP address and since there is a squeeze on IPv4 addresses (everyone uses NAT) IPv6 made sense. Now let's be realistic: most people don't have a full blown IPv6 implementation. But on the flip side, most organizations don't realize that they've already started their implementation. Windows Vista/Windows Server 2008 comes with IPv6 enabled on the stack, so if you have any clients running it than you've began the journey.

IPSec uses ESP tunnels for a couple connections to the DA servers. One is called an Infrastructure connection to establish connectivity to a domain controller/DNS/NAP server. This enables the client PC to process user login requests and also group policy with the latest objects and health validation. This connection is authenticated by a computer certificate.

The second connection is the Resource connection. This is authenticated with both computer and user certificates. As you might have gathered, PKI plays an important role in DA. This tunnel allows access to LOB and the rest of the network if configured.

Topologies

There are several variations of topologies that you can deploy, but most are all based upon the following:

End to End - Going along the lines of defense in depth, DA clients are only allowed access to specific servers for Intranet access. This provides the most security but has the drawback of requiring that those LOB apps reside on Windows Server 2008 or higher. Also, IPSec must be used between the DA server and those LOB servers.

End to Edge - In this topology, encrypted traffic ends at the DA server and enters the Intranet unencrypted. IPSec is not in play on the Intranet side of the DA server. Less secure, but easier to setup.

Connection Process

Here is a play by play of how DA works:

1. DA client detects that it is connected to a network.
2. DA client checks an Intranet web address. If it can connect to this web site, than it determines that it is located inside the Intranet and stops the process. If it's unable to connect it moves to the next step in the connection process.
3. DA client next tries to establish an infrastructure tunnel. This can happen a couple different ways depending on connectivity variables. Most likely it will use a "transition" technology like 6to4 or Teredo but the client does try IPv6 first. If there is some sort of connectivity problem (Firewall) that doesn't pass that traffic, it will use IP-HTTPS for tunneling.
4. Once authentication takes place (remember the computer certificates?) and that the PC is allowed to connect via DA (Computer AD Groups), resource sessions can take place.
5. If you enable NAP on DA clients, health validation begins.
6. Once validated (optional) the DA client begins forwarding traffic based upon the NRPT feature new within Windows 7.

NRPT

Let's examine the NRPT feature a bit. Name Resolution Policy Table is a neat feature in Windows 7. Instead of the resolving names based upon connected interface it resolves them based upon the DNS namespace. So for instance there is an entry in NRPT for foo.com to server 192.168.1.250. If you resolve www.google.com, it will use your standard DNS server on your interface but if you attempt to resolve remote.foo.com, the query will instead be sent to the DNS server 192.168.1.250. As you can imagine, this helps DA resolve internal queries by forwarding them to internal DNS servers rather than global ones who have no idea of what your internal namespace is.

Remember, the main benefits to DirectAccess is an always-on connection to remote clients and remote management for you in IT. Providing the end user with seemless connectivity is always good. Reduce the technology burden!

More DirectAccess content to come!