Hello and welcome to the Microsoft Virtual Academy.

2012 Microsoft Corporation 1

My name is Aydin Asianer. I am a Senior Premier Field Engineer with Microsoft global business
support. This course is about Windows Server 2012 DirectAccess.
2 2012 Microsoft Corporation
Lets take a look at DirectAccess a little bit in detail and understand what it is and how we can use it.
2012 Microsoft Corporation 3
What is Direct Access?
DirectAccess is the capability to have simultaneous corporate network access and internet access
at the same time which means if a users machine is connected to the internet it will get connectivity
to the corporate network at the same time. The other capability about DirectAccess is to give the IT
admins the ability to remote manage the client wherever it is. As long as the machine is connected
to the internet we can manage the client as if it was within our corporate network. This whole
communication is based on IPv6 and secured by IPSec.
2012 Microsoft Corporation 4
Lets understand the components that are involved here a little bit more. On the left hand side what
you can see is a typical corporate network and we have a DirectAccess server just at the edge of
our network. On the right-hand side we have the internet with some clients. You will notice that
there is an IP6/IPv6 node on this slide because this whole communication is again based on IPv6
and secured by IPSec.
Because our internet is based on IPv4 we are still tunneling over IPv4 our IPv6 packets. This whole
communication will be routed to our internal resources through the DirectAccess server so that
means our DirectAccess server is typically acting as a router for us.
On top of all this, we can implement network access protection to check the compliance of the
clients depending on the policies that we have defined as IT admins.
Now that we have seen a brief overview, lets understand the technology and the components that
are involved in detail before we go over to a short demo.
5
Now, this is a typical network. Again, on the right-hand side we have Contoso and on the left-hand
side we have our DirectAccess enabled client. I will talk about the details later on, but lets just get
a brief overview about what is happening here.
The way this works is, wherever the client is getting an internet connectivity the 1
st
thing it will do is
try to find the IPv6 capable DirectAccess server. Again, this whole communication is based on
IPv6, but we are tunneling over IPv4 which means we are using some sort of transition technology
and I will talk about the details later on. Either IP-HTTPS, Teredo or 6to4 to communicate over the
IPv4 internet. This is very typical to the IPv4 DHCP procedure where the client tries to locate a
DHCP server in order to obtain an IP address. The same procedure exists in IPv6 in a similar way
where the client will send an IPv6 router solicitation message to request from the DA server the
prefix for IPv6 communication.
Secondly, the DirectAccess server will then answer with a so-called IPv6 router by providing the
client IPv6 address. Again, I will talk about details later on, but this is the basic procedure around
this.
After the client is getting its IP address what it will do is IPSec and this is based off IP, authenticated
IP and it establishes an IPSec tunnel between the client and the server.
6
After this, the client will try to access some internal resource. In our example here we have a server
called server 1 within our corporate network and we are trying to resolve the name
server1.corp.contoso.com. You might notice that there is something called Name Resolution Policy
Table on this slide. I will talk about the details of this later on, but basically this is a list where you
have a namespace matching a DNS server address. You might notice that this is an IPv6 address
which means whenever we query something with a specific namespace this request will go to that
specific DNS server instead of the one from our ISP which gives us the capability to access the
internet. In this case, because we are trying to access server1.corp.contoso.com this namespace is
matching in our table, we are sending it to our internal DNS server. We send this DNS query over
the secured IPSec communication to the DirectAccess server. The DirectAccess server will
terminate IPSec at that point and will forward to the internal DNS server this query.
7
In this case what will happen is that the DNS server will reply with the quad 4 IPv6 address for
server1.corp.contoso.com. This DirectAccess server takes this reply and passes over to the DA
client over the IPSec tunnel.
8
9
Now that the client knows the IPv6 address of that resource which it is trying to connect to it will,
again, authenticate over IPSec to the server 1 and establish an IPSec communication between
those endpoints and establish something called security associations and we will talk about them
later in detail.
Now that we have established a secure communication between the client on the internet and our
DirectAccess server, the client is able to browse the content of the internal server through
DirectAccess.
Now that we have seen also the overview of how DirectAccess works, lets list a couple of the
benefits of the DirectAccess technology.
10
From a productivity part DirectAccess is always on technology which means whenever the client
gets an internet connection it will be able to communicate with a DirectAccess server without any
delay. There is no explicit user action required which means there is no installation file. There is no
file that the user has to run. There is nothing on the client that gets installed as a software.
Everything is managed by group policy and we will share the details shortly. The end user
experience is pretty much the same as if they were within the corporate network physically.
It is a secure communication based on IPSec and you can implement network access protection on
top of it to access the clients health based on the requirements that you have.
From a manageability perspective, it adds great value for the IT admin because we are now able to
manage the client to whatever it is without having them physically come to the corporate network.
11
Lets take a look at a simple DirectAccess demo and understand what are the components involved
to deploy this technology in a simple way.
Windows Server 2012 DirectAccess does not require IPv6 deployment or a PKI infrastructure to
deploy simplified DirectAccess. In this demo, I am going to show you how you can deploy
DirectAccess with an IPv4 only environment with no existing certificates.
DEMO
To demonstrate this we will use a Windows 8 client who will connect over to the DirectAccess
server to our internal resources. When DirectAccess is configured using the simplified deployment it
automatically creates group policy objects containing the DirectAccess settings. Those are applied
to DirectAccess clients and servers. By default however this would apply the GPO to all the mobile
computers. Since this demo is using virtual machines and we do not have mobile computers it will
have to create a separate security group and apply this in our DirectAccess configuration.
We will now create a separate security group and add our DirectAccess client to this group. To do
this, I am going to our domain controller and creating a new group. I am going to call the
DirectAccess group, DirectAccess Clients and I am going to add my computer called Client 1 to this
group. Once this group is added we can now move on with our DirectAccess deployment. The
remote access server role in Windows Server 2012 combines the DirectAccess feature and the
remote access role service into a unified server role. This new remote access server role allows for
centralized administration, configuration and monitoring of both DirectAccess and VPM based
remote access services.
We are going to configure DirectAccess on our machine called LAB_ EDGE1 which is basically our
DirectAccess server. For this, I am opening the server manager dashboard and I am going to add
the roles and features required to deploy DirectAccess. By default, we will need the server role
remote access so we have to click next, select role-based installation, select the server where we
are going to install this and by default it is selecting Edge1 and select the server role. In this case,
2012 Microsoft Corporation 12
we are going to select remote access and accept the default feature. Once the features
are selected we will click next, accept default with the features and click next and come
over to the remote access role. Within the role we have the role services and you will
notice that direct access and DPN is selected by default so we accept this. We are not
going to configure anything in terms of IIS so we click next, next and confirm the settings
and hit install.
Now, the DirectAccess role service installation is starting and this will take some time.
The installation goes through the Group Policy Management installation, the routing and
remote access server role, the server administration tool and IIS.
Now that the installation has succeeded, we are going to configure DirectAccess. For
this, I am going to close the wizard and click on start and select remote access
management. Confirm yes with your AC. Once the UI is opened, by default we are
coming to the configuration screen. What I am going to do here is select run the getting
started wizard because this is the simplified DirectAccess deployment option. Once I
select this, I will select deploy DirectAccess only as for now I am not interested in VPN
Deployment.
By default, I am going to check some prerequisites and understand what kind of
configuration we have here. What I need to do is now put the name of the server, which is
going to be the public name which the remote access client will connect to. In this case, it
is going to be Edge1.contoso.com. I hit next. Now you can see that the remote access
settings will be applied to a specific group. This is something we want to edit here and
actually to place this one in the group that we created earlier. For this, I am clicking edit,
go over to the remote access clients and hit change and as you can see here it says,
enable DirectAccess for mobile computers only. Since we have Virtual Machines here
we are going to unselect this option and we do not want to deploy DirectAccess to all of
our domain computers as of now so if we remove this group and hit add and type in the
group name that we just created earlier which is DirectAccess clients. Click OK. Click
Next. We are not going to edit the network connectivity assistant here and leave it by
default, hit finish and then hit OK. Now we are ready to deploy DirectAccess on our
server. Now we hit finish. As you can see, it is going now through some settings and
configurations which will create automatically everything needed in order to deploy
DirectAccess for you. You can actually see here that it is generating a self-signed
network location certificate on the server. I will explain what that is used for later on. It
generates group policy, identifies the infrastructure, creates the DirectAccess client
policies and updates them accordingly and validates some security groups which is
required for the clients and the servers.
Once the wizard is finished we just hit close and now we are coming to the configuration
screen and can confirm that DirectAccess is actually configured. Lets move to the
dashboard and confirm that the DirectAccess server is configured properly. As you can
see, everything is showing up in green which means that we have configured
DirectAccess successfully. The only thing left is to go on the client and apply these
settings. For this, the only thing required is to bring up the client and reboot it while it is
connected to the corporate network which is the case right now. I am restarting the
machine and once it is rebooted it will get the new group policy and new group
2012 Microsoft Corporation 12
memberships and should have everything ready to be able to use DirectAccess. So our
client is booting so now we are at the log on screen and I am just going to log onto the
machine with my domain credentials. Once logged on I am going to launch PowerShell
command line to run some commands to understand if the DirectAccess configuration
settings are applied properly.
For this, I am just going to type PowerShell, run it as administrator, confirm UAC. Once
UAC is open I am going to run get-dnsclientnrptpolicy and check if the client has received
the name resolution policy table policy properly. Here you can see that we have actually
received the settings properly because here we have the DirectAccess-
NLS.corp.contoso.com machine listed and if you go a little bit higher we can see the
DirectAccess DNS servers IP address in IPv6 and the namespace, which means for any
query going to corp.contoso.com we are going to use this IPv6 DNS server address.
The other command that I would like to run is called get-ncsipolicyconfiguration which
should give us the network connectivity status indicator settings deployed by the wizard
when we are around the DirectAccess server configuration. Two URLs that you are
seeing at the bottom, the domainlocationdeterminationURL and the
corporatewebsiteprobeURL are used for different things. The
domainlocationdeterminationURL is used to understand if the client is on the internet or
inside the corporate network. The corporatewebsiteprobeURL is used to understand if
our corporate DirectAccess connection is working properly. The other settings we have
not discussed yet so I will leave them out for now, but I will cover them in a later module.
Now that we have confirmed that the settings are properly configured lets confirm that
DirectAccess is actually working. For that, I am going to type in get-daconnectionstatus
to see the status of the connection. In this case, as expected, it is showing status
connected locally which means we are inside of our corporate domain.
What I am going to simulate is to move the client out to the internet by going in the
HyperV settings and selecting the interface called internet. Hit Ok and now my client is
moved to the internet. I will hit no because I dont want to turn on sharing here and give
DirectAccess a little bit of time to come up and configure itself. Just to let you know, on
the internet network I have a server which is running as DHCP and providing public IPv4
addresses to the client and also a public DNS server which will be able to give the
capability to the client to resolve the external name of the DirectAccess server. Now that
we have moved the client to the internet lets run the same command on C: if
DirectAccess is working properly. Now, you can see that when running the same
command, get-Daconnectionstatus, the status is now changed to connect it remotely
which meand DirectAccess is now working. We can confirm this from the UI as well. If
you click on the bottom right corner and we will notice that there is a workplace
connection and it says connected. This means that our DirectAccess connection is
working properly.
Lets ping the ISP website and understand if our internet connection is working properly.
For this, I am going to run a simple ping command to inet1.isp.example.com. As you can
see, I am getting a reply from a public IP address, 131.107.0.1 which is a public internet
server. What I am going to do now is, to ping a machine which is sitting inside of my
corporate network and for this I am going to ping app1. (which is an internal IIS server)
2012 Microsoft Corporation 12
corp.contoso.com and hit enter. Note the format of the IPv6 address return. Since we
did not deploy any IPv6 on our internal network the dynamically created net64 address of
app1 is returned. The dynamically created prefix assigned by DirectAccess server for
net64 will be in the for fdxxx and at the end you can see the 7777 and with the prefix of
/96. right now we have actually connectivity to our internal resources over DirectAccess
using IPv6.
Lets confirm this from the Internet Explorer. First I am going to open Internet Explorer
and then type in http://app1.corp.contoso.com and hit enter. As you can see, the default
IIS website is getting opened. Lets confirm the same by accessing a file share on the
same server. For this I am running run\ \ app1\ files and hit enter. As you can see, I
can access a file share on my internal server and access a file which is example. This is
a shared file. Now that we can see that the connection is working properly, lets go into
PowerShell command line and run a couple of commands to see what kind of IP address
configuration we have received. For this, I am going to type in get-netIPconfiguration-all-
detailed and hit enter. Now it is going to populate all the IP address configurations that
we have on the client in terms of IPv4 and IPv6. Now lets see what kind of IP address
we have. We have the computer name, we have the adaptors and the first IP that we see
is a linklocaladdress which has not too much to do with our DirectAccess connectivity.
Apparently we have a public IPv4 address which is 131.107.0.100. if you go further
down, we will notice that there is an interface now called iphttps and that we have an IPv6
address configured with this IP interface. Now, what we can do is run a specific
command to get more information about the iphttps interface. For this, I am just going to
run get-netiphttpsconfiguration and hit enter. This will give us more information about our
iphttps interface. In this case, you can see the setting that was applied by group policy
directly to the client and which is basically our iphttps URL and reflects our DirectAccess
servers name and DA iphttps connection.
Now that we have seen that we have internal connectivity and interface configuration lets
move on a little bit and move to the IPSec portion. For this, I am launching the Windows
Firewall MMC and to see what kind of rules that we have applied. Lets expand
monitoring and go to the connection security rules which will basically contain what we
have in terms of IPSec rules configured. Now, as you can see we have 3 rules here
which are configured automatically. We did not have to do this manually and if we go
down to the security associations we will see that we have main mode and quick mode
security associations which is basically our IPSec connection to the DirectAccess server.
If we go back to the main mode you might notice that for the first authentication model we
have computer Kerberos and for the 2nd authentication model, user Kerberos. Also, we
do not have any certificate based authentication. This is only possible because of a
feature that was introduced in Server 2012 which is called Kerberos Proxy and this was
deployed by the entire access wizard when we run through the setup.
Now that we have seen the client side of the connectivity, lets move onto the server and
confirm the same. For this, I am going to open up the DirectAccess server again and this
time I am going to click on remote client status to get an overview about the connectivity.
Here you can see that we have a DirectAccess client. We have some information about
the user name, the host name, what kind of protocol it is using, the duration of the
communication and some access details at the bottom. What port it is using, what kind of
2012 Microsoft Corporation 12
IP address it is connected to and on the right-hand side you have even more details on
how many bytes gets transferred in and out, when did the connection start and what kind
of authentication it is using. If you double click on the client 1 you will get more details
about the connectivity and can see what and where and when the client connected to the
DirectAccess server.
This is basically how you deploy DirectAccess in a simplified deployment method. As you
saw, we did not require any changes to our infrastructure and could easily apply
DirectAccess with a few clicks.
2012 Microsoft Corporation 12
Thank you for taking time to view this content.
2012 Microsoft Corporation 14
15 2012 Microsoft Corporation
2012 Microsoft Corporation 16