Imagine if you could be anywhere on the planet,
connected to the Internet and still have no hassle access to all of your
corporate assets. I am sure many of you are thinking, “I already have
that! I VPN in, and...”. Well, to be more specific, how about the same
LAN style corporate access, but without the VPN hassle?
Well, with Windows 2008 R2,
Microsoft released an amazing new feature called DirectAccess, and the
name says it all. DirectAccess allows you and your users to gain access
to the internal corporate resources in your environment from the
Internet, without first connecting to a VPN, and without requiring user
intervention to connect!
The benefit is apparent
from a user’s perspective. They have access to corporate resources such
as Web pages, file shares, and applications from any Internet-connected
location. It is a secure connection and the user experiences mimics
being directly connected to the corporate environment, thus giving the
user a seamless experience between being in the office and out of the
office.
The benefits that may not be as
apparent are the advantages DirectAccess bring into play for the
administrative team. Administrators can utilize DirectAccess technology
to their advantage in a number of ways. One way DirectAccess lessens the
burden of the help desk is by reducing the learning curve associated
with VPN access. When users are in the office they have one way of
accessing resources. Put them out on the Internet, and now they have to
battle with VPN connections before their resource access returns.
Account lockout problems can occur, issues around client VPN software
must be addressed, and of course, users have to be taught to utilize the
software as well.
By deploying
DirectAccess connections into corporate resources, look and act the same
for a user regardless if they are on the Internet or connected directly
to the Intranet. The maintenance and management of VPN software and
infrastructure is something that can be scaled down as its usage
lessens. Additionally, the Windows 7 and Windows 2008 R2 native
DirectAccess feature set leaves your users with little to nothing to
learn, since the connection is seamless.
Another benefit that
DirectAccess brings to administrators relates to system maintenance. In
most corporate environments, mobile users are a wild card. Since they
only connect to the environment intermittently, keeping them patched and
up to date with the latest policies can be tricky.
Normally,
an administrator must rely on a user to either VPN into the corporate
network or actually walk into a company facility and connect to the LAN.
This can make the time between updates unpredictable and it can leave
users’ machines in a vulnerable state. By being able to access a user’s
machine whenever they are connected to the Internet, the story changes
dramatically.
With DirectAccess, the user
merely has to connect to the Internet from anywhere in the world. Once
on the Internet, their computer will automatically connect to the
corporate network, authenticate, and give them access to network
resources while at the same time giving your network maintenance tools
the ability to connect to them. By being able to patch and manage
policies on machines that normally might not connect into the network
for long durations at a time, you can be that much more efficient at
keeping your corporate systems up to date. In the next sections, we will
explore DirectAccess in more detail to see how you can choose to
utilize it to secure and also enable your mobile user workforce.
DirectAccess infrastructure requirements
In order to deploy
DirectAccess, you will need to take into consideration the
infrastructure dependencies that exist with DirectAccess. The first key
thing to be aware of with DirectAccess is that both IPv6 and IPsec play a
critical role in the deployment. Regardless of the deployment model
chosen, users on the Internet will only be able to gain access to
servers on the Intranet capable of running IPv6.
IPSec is the protocol
of choice in routing traffic securing across the Internet; however, once
a client has connected into the DirectAccess servers and been granted
Intranet access, IPSec encryption becomes an option within the LAN. It
is recommended to continue IPSec within the internal network, but
ultimately, it is the administrator’s choice by design. Regardless of
whether IPsec is in use, only the IPv6-capable servers on the Intranet
will be accessible by DirectAccess users.
Other DirectAccess infrastructure requirements include:
Active Directory Domain Services
Group Policy
At least one Windows 2008 Domain Controller
DNS services that support DNS message exchanges over Intrasite Automatic Tunnel Addressing Protocol (ISATAP)
A PKI infrastructure for IPSec certificate issuance
DirectAccess protocols
Multiple
protocols are in use when a client is utilizing DirectAccess. At times,
the connection circumstances will dictate which protocol is to be
utilized, while at other times, the architecture design will indicate
which protocol is more appropriate. The following protocols may be
utilized as a part of DirectAccess encapsulation technology:
Intra-Site Automatic Tunnel Addressing Protocol —A transition technology that provides for IPv6 unicast communications between IPv4/IPv6 hosts across an IPv4-only Intranet.
6to4 —Provides for unicast communications between IPv4/IPv6 hosts and IPv6-capable sites across the Internet
Teredo —Provides for unicast communication between NAT’ed IPv4/IPv6 hosts across the Internet to IPv6 capable sites
IP-HTTPS —Tunnels IPv6 within an HTTP over SSL connection, allowing for connectivity even while in restricted sites.
IPSec —Tunnels IPv6 across IPv4 networks.
If a client connected to the
Internet has been assigned a publically routable IP address, they will
utilize the 6to4 protocol to attempt connection into the DirectAccess
architecture. If the client is behind a NAT, then they will instead
utilize the Teredo protocol to connect. If the client cannot use either
6to4 or Teredo, it will then attempt to connect with IP-HTTPS. However,
something to keep in mind is that IP-HTTPS is a slower technology, and
there is the potential impact on client performance.
Selecting a DirectAccess model
Before jumping headlong
into a DirectAccess deployment, the first step an administrator must
take is to determine the DirectAccess model they would like to employ.
The level of security required across organizations will vary in
stringency, and administrators have the choice to build a design that
maps to the organization’s specific security needs. Microsoft defines
three DirectAccess models that can be evaluated to determine the
architecture that is a best fit for your environment. The three main
access models that we will discuss are:
Full Intranet Access
Selected Server Access
End-to-End Access
In some environments, the
thought of allowing access to internal protected company resources from
the Internet seems daunting, while in others, the accessibility is
readily welcomed. Regardless of the security stance of your
organization, you can build a secure access model to meet your business need.
All three of the access models follow some of the same security
principles and contain the same infrastructure elements. Let us review
the high-level similarities across the three access models first.
The first commonality is:
to ensure that data transference is secure when traversing the Internet,
DirectAccess utilizes a two-step IPsec Encapsulating Security Payload
(ESP) tunnel to connect. The first connection made by the client
regardless of the access model will always be an infrastructure tunnel.
The Infrastructure tunnel enforces computer authentication.
Full Intranet Access
This deployment model is the
most similar to what exists today in many companies with VPN solutions
deployed. In the traditional VPN model, the user makes an initial
connection to a server on the perimeter, and once authenticated, is
typically able to browse the internal network without restriction. With
DirectAccess configured in the Full Intranet Access model, the scenario
is similar.
The first step in
connection is always the infrastructure tunnel. Once the infrastructure
tunnel is complete, the user will authenticate and establish an
intranet tunnel. The intranet tunnel users both computer and user-based
authentication and it is used to connect to the DirectAccess server on
the perimeter. Once the intranet tunnel has been established to the
DirectAccess server, the client can browse and access LAN-based
resources as if they were directly connected.
The DirectAccess server is
functioning as an IPSec gateway and all IPSec traffic from the Internet
terminates at the DirectAccess server. Transmissions from the client to
the internal applications are still sent with the IPv6 protocol, but
without the IPSec encryption that was present from the client to the
DirectAccess server. The DirectAccess server continues to encrypt and
decrypt IPSec traffic between the client and the Intranet resources.
For environments with Windows
2003-based resources in the LAN, this is the best deployment model.
Since Windows 2003 servers do support the use of IPv6, but not IPSec
with IPv6, they will only be accessible while the DirectAccess server is
functioning as an IPSec gateway. Any resources that are not able to
support IPv6 will not be accessible without the deployment of a
third-party translator and DNS gateway.
Full Intranet Access with Smart Card Authentication
The Full Intranet Access
with Smart Card Authentication model represents the same architecture as
the Full intranet Access model, just with the addition
of Smart Cards for an additional layer of user authentication
protection. The DirectAccess server can be configured to enforce the
user of Smart Cards on the Intranet tunnel before allowing user access
to resources.
Selected Server Access
If your organization requires
more selective access to internal resources for external clients, then
this is the deployment model for you. By utilizing the Selected Server
Access model, you enforce that client to utilize the IPSec Encapsulating
Security Payload (ESP). It enables peer-to-peer authentication
utilizing computer credentials and allows the clients to validate the
identity of the server they are connecting to. This way the clients can
determine if IPSec is required to connect to specific services on the
Intranet.
In environments that
contain the services of a sensitive nature, this model allows you to
single out specific targets for Intranet-based IPSec encryption while
traffic to other services on the Intranet remains clear. All traffic to
and from the Internet is still secured by the IPsec gateway services
provided by the DirectAccess servers.
End-to-End Access
In the End-to-End Access
model, resources on the Intranet are made accessible to Internet users
directly. End-to-End Access enforces IPsec from the DirectAccess client
and the Intranet resource in a point-to-point fashion. IPSec peer
authenticate using computer credentials should be configured and ESP is
recommended.
Overall, in this model, the
DirectAccess servers get a break. Since all tunneling is performed
directly between the client on the Internet and the resource on the
Intranet, much of the overhead is offloaded onto the endpoints instead
of relying on the DirectAccess server for translation. The DirectAccess
server simply performs pass-through for the IPSec traffic and does not
function as a gateway in this model.
