Direct Access – SCCM – Managing internet clients

  • [アーティクル]

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
image

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.
image

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.
image

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.
image The clients settings provides a mechanism for editing clients that are allowed through Direct Access.  The server option is used to configure connectivity, management and authentication policy as shown.
image

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.
image

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.
image

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. image

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
image

We will start our example by selecting the corporate network.  image

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.
image

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.
 image
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.

image

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.
image
Going to the client I submit a new heartbeat DDR.  Note the system time.
image In the SCCM console we see the last heartbeat time has come current.

image

Nothing unexpected here – the client is on the intranet.  So shifting the client back to the internet lets do the same test.
image Back in SCCM – we see the last heartbeat date has again updated and is current.
image A simple demo – but a great way to show how powerful Direct Access is and how seamlessly SCCM can work with it.  Intrigued?  I hope so – it’s an awesome technology.

Comments

  • Anonymous
    August 01, 2010
    good post... Once Windows XP support stops completely not required Native mode....

  • Anonymous
    August 02, 2010
    Finally someone writes about this, thank you! One question: What are you supposed to define in the boundaries for SCCM. the Ipv6 prefix?

  • Anonymous
    August 02, 2010
    Hey Max - I don't have this setup any longer but would imagine the boundary you shuld enter is the boundary displayed in the SCCM control panel applet.

  • Anonymous
    January 20, 2011
    Great post... do all windows XP machines have or can be configured to have IPv6 working on them, or is it with some service pack/patch/hotfix? Thanks.

  • Anonymous
    March 01, 2011
    Hi Steve, I was wonderiing how to deal with client auto-site assignment? Do I have to add my DirectAccess server or my corporate IPv6 prefix as SCCM IPv6 boundary? King Regards, Ronny

  • Anonymous
    April 20, 2011
    Can you acces the any shares on the direct access server?

  • Anonymous
    April 21, 2011
    You should be able to access shares on the direct access server just as if you were on the local network.