Feeds

Can DirectAccess take over the world?

Significant Server 2012 overhaul, but some niggles to iron out

HP ProLiant Gen8: Integrated lifecycle automation

IPv6 for the masses

The original implementation of DirectAccess as an IPv6-only connection broker was as useful as a chocolate teapot. It is a necessary technology to cope with the future, but was put in place more than five years before it would be required by anything other than edge cases.

The Server 2012 version works (more or less) without the IPv6 requirement. The client computers need to have the IPv6 stack installed and enabled and the DirectAccess server needs a globally addressable IPv6 address.

(This doesn't have to be provided by the ISP; IPs handed out by transition technologies such as Teredo tunnelling, an IPv6 transition mechanism, will do.)

If the client does not have a proper IPv6 address, it can connect to the DirectAccess server using any of the common transition technologies. If the client is in a place where things like 6to4 or do not work (which covers a lot of places), the client can establish an SSL tunnel to the DirectAccess server (IP-HTTPS), obtain an address from there and communicate with the corporate network entirely through this tunnel.

This allows clients with IPv4 network connectivity to establish an IPv6 connection with the DirectAccess server. IPv6 connectivity is a basic element required to use DirectAccess. If the internal servers were all IPv6, you'd be good; most aren't.

The NAT64 and DNS64 protocol translators enable clients to access IPv4 servers and resources across that IPv6 DirectAccess connection.

Additional technologies

Once the basic IPv6 connectivity between server and client exists, additional applications are required to make everything work properly. The NLS is required to let clients determine if they are connected to the corporate network (and thus should not require DirectAccess) or are connected via the internet (at which point DirectAccess will connect automatically.)

If NLS detects that the client is not part of the domain, NRPT is enabled on the client. This is a fundamental element of DirectAccess and requires some exploring.

Briefly, NRPT is a DNS for DNS servers. Normally, you query a DNS server to discover the IP address of a server you would like to communicate with. NRPT is a technology you query when you are not sure which DNS server you should use to fulfill that request, so you look it up against the NRPT rule set.

Get it together

The take home is simple: if you are not on the corporate network (as determined by NLS) and you attempt to access any DNS requests that match the subnets, IPs or fully qualified domain name suffixes used by the corporate network, NRPT tells your computer to query the corporate DNS servers and not simply use the DNS servers coded into the NIC configuration.

Group policy is how all these technologies are lashed together. It is also why your clients must start out domain-joined: when you first deploy DirectAccess, the configuration for all the subsidiary technologies (Windows Firewall, NLS, NRPT, IP-HTTPS) is pushed out to the clients via GPO.

The client systems will receive changes in configuration even when not logged in by a user because the operating system periodically checks in via DirectAccess just as if it were on the local network.

Other options

I have a few niggles about DirectAccess, starting with overhead. It seems silly to utilise IPv6 inside an SSL tunnel running across an IPv4 network, then getting network addresses translated simply to access IPv4 resources on the corporate network.

The other option is little better: the Teredo network can be excruciatingly slow. Teredo relays are generally saturated because the bandwidth they can provide any given client is jittery and unreliable. You can set up your own Teredo server/relay if you want, but why bother, given that it doesn't offer you much over the IP-HTTPS approach?

If your network does not contain IPv6 servers (and many don't) then DirectAccess is of questionable value. The client is built directly into the operating system, but a traditional SSL VPN such as Microsoft SSTP or OpenVPN would give you great connectivity with a lot less hassle and fewer moving parts to worry about.

The advantage of DirectAccess is that as an IPv6 technology it was designed to be always on. There is no connecting as with a traditional VPN: it is simply there, the same as if your computer were plugged in to the corporate LAN.

DirectAccess server requirements

The DirectAccess server must have a globally addressable IPv6 address. It doesn't really matter where it gets it from, so long as it can talk to the internet using that IP. The DirectAccess server must be domain joined. It cannot be a domain controller.

The DirectAccess server must have Windows Firewall enabled and needs to be able to use Intra-Site Automatic Tunnel Addressing Protocol to ensure cross-site connectivity. You must create a Network Location Server, NAT64 and DNS 64 or allow the DirectAccess 2012 wizard to do so for you. IP-HTTPS is required for almost all real-world scenarios; you can set that up yourself or let the wizard do it for you.

Global domination

Setting up DirectAccess to allow Windows 8 to connect to Server 2012 takes just three mouse clicks. If you want to get Windows 7 to play there is more to it.

This is a shame, as few big organisations are in a rush to deploy Windows 8. That is not how enterprise lifecycles work.

Windows 7 is not legacy insomuch as it is the new XP. A large chunk of the world will be using and supporting this until at least 2020.

DirectAccess represents a massive ease-of-use improvement in corporate IPv6 security, but it won’t gain any traction if it is a pain to set up and maintain.

DirectAccess is not just good technology, it is great technology. Microsoft should port the Windows 8 DirectAccess client to Windows 7 as a goodwill gesture to further the security of the future internet.

If you can deploy DirectAccess – all your mobile clients are Windows 7 or Windows 8 Enterprise – then you should. It provides remote users with unprecedented ease of use and sets you on a path towards a future where IPv6 access for your organisation is done securely.

When looking to set up connectivity to your corporate network bear in mind what DirectAccess really is: an access control connection broker for IPv6 connectivity and not a VPN. This new IPv6 way of thinking about access is the inevitable future.

For more traditional connectivity requirements, turn to the other features within the Remote Access role. They provide a combination of technologies allowing a secure transition from the old to the new, from our familiar IPv4 world to the wild and whacky directly accessible world of IPv6. ®

DirectAccess client requirements

Clients must be Windows 7 (Enterprise or Ultimate) or Windows 8 (Enterprise only). Windows 7 clients are considered legacy clients and there are some additional steps required to get them to work. Linux, Unix and OSX are supported via third-party software.

Clients must have a globally addressable IPv6 address. They can obtain this through the standard transition mechanisms or by using IP-HTTPS to obtain one from the DirectAccess server. The clients must be domain joined.

Eight steps to building an HP BladeSystem

More from The Register

next story
THUD! WD plonks down SIX TERABYTE 'consumer NAS' fatboy
Now that's a LOT of porn or pirated movies. Or, you know, other consumer stuff
EU's top data cops to meet Google, Microsoft et al over 'right to be forgotten'
Plan to hammer out 'coherent' guidelines. Good luck chaps!
US judge: YES, cops or feds so can slurp an ENTIRE Gmail account
Crooks don't have folders labelled 'drug records', opines NY beak
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
FLAPE – the next BIG THING in storage
Find cold data with flash, transmit it from tape
Seagate chances ARM with NAS boxes for the SOHO crowd
There's an Atom-powered offering, too
prev story

Whitepapers

Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.