Installing and Configuring Windows Server 2012 Direct Access:
What is DirectAccess?
DirectAccess, introduced in Windows Server 2008 R2, is a remote access feature allowing connectivity to corporate network resources without the requirement of Virtual Private Network (VPN) connections. DirectAccess at the time only supported domain-joined Windows 7 Enterprise and Windows 7 Ultimate edition clients. Windows Routing and Remote Access Server (RRAS) will continue to provide traditional VPN connectivity for legacy clients, non-domain joined clients, third party VPN clients and site-to-site server connections. RRAS in Windows Server 2008 R2 must be deployed and managed separately from DirectAccess as it cannot coexist on the same edge server.
In 2012, DirectAccess offered with Windows Server 2012 R2 combines the feature and the RRAS role service into a new unified server role. This new Remote Access role allows for centralized configuration, administration, and monitoring of both VPN-based remote access services and DirectAccess. Windows Server 2012 R2 DirectAccess also provides multiple updates and improvements to address deployment blockers and provide simplified management.
These features include:
- DirectAccess and RRAS coexistence
- Simplified DirectAccess Deployment
- Removal of PKI (Public Key Infrastructure) as prerequisite
- Built in NAT64 and DNS64 support for IPv4 only resources
- Support for DirectAccess behind a NAT device
- Load Balancing Support
- Multi Domain Support
- NAP Integration
- Manage-Out to clients support
- User Monitoring / Server Status / Diagnostics
- IP-HTTPS performance improvements
- Server Core Support
- Multisite Support
Windows 8.1 Enterprise and Windows Server 2012 R2, DirectAccess deployment is also now simplified with a working configuration deployed in a few clicks. However, options are also available to allow for DirectAccess accessibility through a multitude of deployment options should the standard configuration not meet your organizations requirements. These deployment options include:
- Single Site Remote Access
- Remote Access in a Cluster
- Multiple Remote Access Servers in a Multisite Deployment
- Remote Access with OTP Authentication
- Remote Access in a Multi-Forest Environment
- Remote Access with Network Access Protection
- Remote Access in the Cloud
This guide will explain how to install and configure DirectAccess on a Windows Server 2012 behind a NAT router with one adapter. To keep this guide as simple as possible, I will not explain the different steps and why it must be like that. Simply follow the guide and you will have a working DirectAccess.
The Prerequisites are:
If you are following this guide, you will need:
- A domain administrator. For this guide I am always logged in as a domain administrator.
- A domain controller
- A Remote Access server (also called DirectAccess)
- One public IP
- An external DNS record that points to your public IP. I used DynDNS.
- If behind a NAT device, forward port 443 from your public IP to the Remote Access server (internal IP)
DynDNS is free for two weeks, so give it a try. Edit: Someone mentioned freedns.afraid.org which is completely free, and is actually easier to use! Make a new account and click add a subnet!
Configuring DirectAccess Setup:
All my servers are running Windows 2012, and all my clients are running Windows 8. This guide is for Windows 8 clients, and will be edited soon to support Windows 7 clients. I just want to see DirectAccess work! I do not have a PKI nor do I have a NLS (for those who have worked with DirectAccess before, you know what this is.)
I have one domain controller and one Remote Access server. That’s it. My domain is called syscomworld.local, and everything is behind a NAT router. The firewall is very strict here. Both servers are actually virtual machines running on the same physical machine.
Open Server Manager and click add server roles. Scroll down to Remote Access and install it with the default settings.
Before we configure Remote Access, we will have to do a couple of things:
– Make a security group in Active Directory. Mine is called DA_Klienter. Your client machine has to be a member of the domain and the security group.
– Make sure your firewall is correctly configured. Port 443 has to be open, and your external IP should be forwarded to your Remote Access server.
– Remove ISATAP from the global blocking list on the domaincontroller, you can do this by running this command
dnscmd /config /globalqueryblocklist wpad
Open Remote Access Management from the metro menu. In the console, click Run the Getting Started Wizard and choose deploy DirectAccess and VPN. Select behind a NAT device with a single adapter and type in your external DNS.
Let us start by configuring step 1. This guide will deploy full DirectAccess for clients and remote management.
Remove Domain Computers and add the security group you made earlier. Since my clients are virtual machines, I have to uncheck Enable DirectAccess for mobile computers only.
In this lab, I will not be setting up a helpdesk. Choose an appropriate name for DirectAccess, I went for SyscomVPN. This will show up on the clients when the user clicks on Network to log into a wireless network.
Move over to step two. Companies that looked into DirectAccess and decided not to implement it into their system probably did so because DirectAccess required a specific topology to work. Now we have three different choices, where I find behind an edge device (with a single adapter) the easiest one. Insert your external DNS (I do like pie) you made with DynDNS and click Next.
Certificates has become significally easier to handle (for windows 8 clients that is). I will bring up later on how to make this work for Windows 7 clients. Check the box Use a self-signed certificate created automatically by DirectAccess.
My clients will be logging in with their Active Directory credentials. If you look at the bottom, you will see where we need to check if we want Windows 7 clients to use this configuration. If I enable this, I will have to insert a certificate on the NLS, which I do not want to at this moment.
I will be deploying the NLS on the Remote Access server. However, the NLS should, and is recommended, be deployed on a different server. For now, check the mark the network location server is deployed on the Remote Access server. This will be using a self-signed certificate.
*Check comments for why you should install Network Location Server on a different server.
Click next until you finish the wizard.
If you do not want DirectAccess users to access certain servers, you can make a security group in AD that contains those servers you want them to be able to access. Since this is a lab environment, I just clicked Finish with the default settings.
Now we are done with all the steps, click Finish, which you will find at the bottom right hand side of the configuration page.
Review of all the settings we just configured. Click apply when done looking it over.
Open the Dashboard page and wait until you see green checkmarks popping up. You might have to click refresh now and then.
Test a Win8 client
If the client already is a member of the domain, logg out and back in again. The client will then configure itself to use DirectAccess because it says so in the GPO.
When logged in, open your desktop and check Available Networks. You should see an extra connection there, that’s your DirectAccess. I called mine for SyscomVPN (you change the name in Step 1).
My client is connected to the domain right now. When outside the domain, it will say Connected (or Connecting if it doesn’t work). You can get the logs if you right click it, so no need for DirectAccess Connectivity Assistant anymore.
I just used my cellphone to test if this worked.
If it is working, then you can test this by making a shared folder on one of the servers and see if you can access it outside the domain.