First published on MSDN on Jul 30, 2010
Do you have internet based clients that you want to manage? Does the idea of switching to SCCM native mode to manage those client make you nervous? Do you have Windows 2008 R2 servers in your environment and are the internet systems you want to manage running Windows 7 (Enterprise or Ultimate) or Windows Server 2008 R2? If you said yes to all of these questions then you might just be interested in taking a look at Direct Access (DA).
Direct Access is NOT a feature of SCCM but is a feature of Windows 2008 R2. There are several advantages to choosing Direct Access over native mode configuration in SCCM
1. There is no requirement to implement SCCM native mode
2. The feature is part of Windows 2008 R2 so likely would be supported by other than the SCCM team – yet SCCM can take full advantage of the service.
3. The SCCM team does not need to worry with certificate infrastructure support. Yes, there are certificates required by Direct Access but this is generally not something the SCCM team needs to worry about.
4. The SCCM client managed through Direct Access is just like a client installed on the internal LAN.
So if Direct Access isn’t a feature of SCCM why discuss it here? Simply put – Direct Access is cool and is an elegant way to manage systems on the internet just as if they are connected to the physical LAN. But, before SCCM can make use of this technology it has to be deployed. Having SCCM administrators aware of the technology and wanting it implemented adds justification to moving forward with deployments.
That said, lets talk about Direct Access.
First, what specifically is Direct Access. Direct Access is a way to connect a system seamlessly and securely to the corporate network from any internet connection. Direct Access communication is encrypted either from the client to the edge of the corporate network or from the client to the target server inside of the corporate network. Direct Access has full support for smart cards as well as other authentication security. Also, systems connecting via Direct Access don’t need to use any VPN solution – the connection is automatic after connecting to the internet.
Now that we know what Direct Access is – why would one want to implement it? The main reason has already been mentioned – the ability to have an internet connected system appear as if its on the corporate LAN. From an SCCM perspective, this makes managing those systems very easy.
OK, so you are starting to get interested. What specific OSes are supported again? Thats really a two pronged answer.
Direct Access CLIENTS:
-Windows 7 (Enterprise or Ultimate)
-Windows 2008 R2
Direct Access TARGETS (systems that can understand a direct access client)
-Systems that support IPv6
-Windows XP
-Windows 2003
-Windows Vista
-Windows 7
-Windows 2008
-Windows 2008 R2
That seems a bit confusing but it’s not really. The bottom line is that Direct Access requires IPv6 in order to operate. So, any system a Direct Access CLIENT tries to access must also have the ability to communicate via IPv6. In addition, any application the client tries to communicate with must be able to handle IPv6.
So does this mean that you need a full scale implementation of IPv6 before introducing Direct Access to the environment? In a word, no – but that discussion goes a bit beyond what we are trying to do here for the SCCM admin. Suffice it to say – the IPv6 component really isn’t that difficult and you will see some of that in the screenshots coming up.
So what are the components of Direct Access?
1. Direct Access client – this is a domain joined system running one of the supported operating systems.
2. Direct Access Server – this is a domain joined server in the environment running the Direct Access service
3. Network Location Server – this is a server system whose purpose is to determine Direct Access client location – whether on the internet or intranet.
4. Certificate Authority – this is a server running certificate services. All Direct Access clients require a computer certificate and Direct Access servers require a web certificate.
5. Certificate Revocation List Distribution Point
6. IPv6 – there are three implementation choices here
-Native IPv6 environments
-ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).
This protocol allows encapsulating IPv4 traffic in an IPv6 tunnel so even IPv4
systems can work with Direct Access.
-NAT-PT/NAT-64
This is a method of translating traffic into a format understood by non IPv6 aware
applications.
What are the supported scenarios for implementing Direct Access? There are three
Full Intranet Access
This scenario has the Direct Access client communicating through the internet to the Direct Access server. Note that there are two IPv6 protected tunnels created – one to access AD/DNS and the other to access application servers. This represents an ‘end to edge’ scenario
Selected Intranet Access
This scenario is similar to the full model except here there are only a select set of systems that should be accessible by Direct Access clients. You will see where to configure this in just a minute when we look at the setting of the Direct Access servers.
End to End Access
This scenario is one where encryption is done all the way from the Direct Access client through the Direct Access server to the target systems inside the network.
With this understanding let’s explore a Direct Access environment. In our demo lab we have several systems representing the components we have discussed so far. Lets walk through each server type and then take a look at Direct Access in action.
DA1 – Direct Access Server
This is the key server for the Direct Access environment. There are two ways to configure Direct Access - simply install the component and configure it or make use of Forefront UAG Management. My preference is to make use of ForeFront. In Forefront we have an option for configuring Direct Access. When we select that option we have a layout for our Direct Access environment. 
Note here that ISATAP is enabled to handle translation since Direct Access is operating inside an IPv4 network.
There are also configurations for the application server – here is where the selection is made whether to use ‘end to edge’ or ‘end to end’ connectivity as shown.
Lastly is the configuration for Infrastructure Servers such as the network location server which helps determine whether the client is on the internet or intranet.
In addition to this we have the requirement for a certificate authority (CA). In this example the CA is installed on a domain controller. Looking at the CA we can see that all of the systems participating in Direct Access do have certificates. The yellow highlight shows one of my test Direct Access clients with a computer cert and the green highlight shows my Direct Access server with a web cert.
With the summary of the Direct Access environment complete, let’s see it work with SCCM. For my test client note that I have three Direct Access network configurations
We will start our example by selecting the corporate network.
Reviewing the IP settings after my IP renew I can tell I’m on the corporate network and have a 10. IP address – exactly as it should be when on the internal network. A further test shows that I’m able to access a server share on my SCCM server from this client.
Lets mix it up – now the network settings are configured so the client is on the internet. The IP settings now reflect the test client on the internet network. 
Notice now that my IP range has changed to the new network – the network name is isp.com and I have an IPv6 address (note the Terado Tunneling Pseudo Interface) and also have a 6to4 configuration which is our NAT64 configuration discussed earlier. Note the ISATAP setting shows not connected – there can be some delay connecting that protocol but we have enough to allow our connection to succeed – so lets see our test again – can we get to the same SCCM share? Under traditional circumstances the answer is no – we would require a VPN solution but with Direct Access – we connect just fine as shown.
Wow Steve – thats amazing – you can connect to a share – WooHoo…thats exciting.
I could stop here. There may not be bells and whistles and lots of excitement but I’ve just demonstrated the significant power and advantage of Direct Access. But let’s actually do something with the SCCM client through direct access.
I’ve shifted the client back to being on the corporate network. When I look at the SCCM server I can tell when the client last submitted a heartbeat DDR. 
Going to the client I submit a new heartbeat DDR. Note the system time. 
Nothing unexpected here – the client is on the intranet. So shifting the client back to the internet lets do the same test. 
