DA_Module_1 Overview and Deployment

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

Let’s take a look at DirectAccess a little bit in detail and understand what it is and how we can use it.


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.


Let’s 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, let’s 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 let’s just get

a brief overview about what is happening here.

The way this works is, wherever the client is getting an internet connectivity the 1st 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, let’s 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 client’s 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

Let’s 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,


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. Let’s 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


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 let’s 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 don’t 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 let’s 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.

Let’s 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)


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.

Let’s 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. Let’s 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, let’s 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 let’s 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 let’s

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. Let’s 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, let’s 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


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.


Thank you for taking time to view this content.


15© 2012 Microsoft Corporation


Documents

DA_Module_1 Overview and Deployment