12/13/2012
10/24/2012
DirectAccess for Windows Server 2012 Installation & Configuration Guide
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, or should at least.
Prerequisites
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!
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.
Installation
Open Server Manager and click add server roles. Scroll down to Remote Access and install it with the default settings.Configuration
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.
Step 1
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.
Step 2
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.
Step 3
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.Click next until you finish the wizard.
Step 4
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.
10/07/2012
IPSec Modes: Transport and Tunnel
Comparing Transport and Tunnel
Modes
The bottom line in understanding the difference
between these two is this: tunnel mode protects the original IP datagram as a whole, header and all, while
transport mode does not. Thus, in general terms, the order of the headers is as
follows:
- Transport Mode: IP header, IPSec headers (AH and/or
ESP), IP payload (including transport header).
- Tunnel Mode: New IP header, IPSec headers (AH and/or ESP), old IP header, IP payload.
Again, this is a simplified view of how IPSec
datagrams are constructed; the reality is significantly more complex. The exact
way that the headers are arranged in an IPSec datagram in both transport and
tunnel modes depends on which version of IP is being
used; IPv6 uses extension headers which must be arranged in a particular way
when IPSec is used. The header placement also depends on which IPSec protocol is
being used: AH or ESP. Note that it is also possible to apply both AH and ESP to
the same datagram; if so, the AH header always appears before the ESP
header.
There are thus three variables and eight basic
combinations of mode (tunnel or transport), IP version (IPv4 or IPv6) and
protocol (AH or ESP). The two topics on AH and ESP describe the four format combinations
of transport/tunnel mode and IPv4/IPv6 applicable to each protocol. Note that
ESP also includes an ESP trailer that goes after the data
protected.
You could probably tell by reading these
descriptions how the two modes relate to the choice of IPSec architecture from
the preceding topic.
Transport mode requires that IPSec be integrated into IP, because AH/ESP must be
applied as the original IP packaging is performed on the transport layer
message. This is often the choice for implementations requiring end-to-end
security with hosts that run IPSec directly.
Tunnel mode represents an encapsulation of IP
within the combination of IP+IPSec. Thus, it corresponds with the BITS and BITW
implementations, where IPSec is applied after IP has processed higher-layer messages and already added its header. Tunnel mode
is a common choice for VPN implementations, which are based on tunneling
of IP datagrams through an unsecured network such as the Internet.
 Key Concept: IPSec has two basic modes of operation. In transport mode, IPSec AH
and/or ESP headers are added as the original IP datagram is created; this mode
is associated with integrated IPSec architectures. In tunnel mode, the original
IP datagram is created normally, then the entire datagram is encapsulated into a
new IP datagram containing the AH/ESP IPSec headers. This mode is most commonly
used with “Bump In The Stack” and “Bump In The Wire” implementations. |
Additional Deployment Options and Considerations
Force Tunneling, PKI, Smart-Card with DirectAccess from Technet
By default, remote DirectAccess clients are able to access the Internet, the intranet, and their local subnet simultaneously. DirectAccess clients are configured to send all intranet name query requests to their intranet DNS servers, and unrecognized or exemption name query requests to their ISP’s DNS servers. This is the default and recommended operating mode of DirectAccess.
To force all of your intranet and Internet traffic to flow through the DirectAccess connection, you can use Force Tunneling. You can enable Force Tunneling with the following Group Policy setting on the Group Policy object for your DirectAccess clients:
Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network
When Force Tunneling is enabled, all traffic from the DirectAccess client must be IPv6 traffic and will be routed to the intranet over an IP-HTTPS tunnel. Force Tunneling-enabled clients will still be able to access any resources on their local subnet, such as network printers, but any network traffic beyond the local subnet must be IPv6 traffic.
To reach resources on the IPv4 Internet when Force Tunneling is enabled, use an IPv6-capable Web proxy server. Alternately, you can use NAT-PT device on your intranet and route the resulting IPv4 Internet traffic to your IPv4-based Web proxy servers. To reach these resources for IPv4 Internet traffic, you must configure the following additional NRPT rule in the DirectAccess Setup Wizard:
- Name suffix set to “.”
- DNS server IPv4 or IPv6 addresses set to the IPv6-capable proxy server or NAT-PT
 Note |
|---|
| Due to the infrastructure requirements and reduced performance for accessing IPv4 Internet resources, Microsoft does not recommend the use of Force Tunneling for DirectAccess. |
With DirectAccess, IT staff has the ability to remotely administer DirectAccess client computers. This might include pushing out security updates, retrieving hardware and software inventory reports, installing application updates, or even helping a user perform a complex task with Remote Desktop. Since DirectAccess client communications use IPv6 exclusively, any application an administrator uses to connect to a remote DirectAccess client must be IPv6-enabled.
Additionally, when an administrator uses an application that connects to a DirectAccess client using Teredo as the transition technology for sending IPv6 traffic over the IPv4 Internet, a firewall rule for that application with the Edge Traversal flag enabled needs to be configured on the client computer. You can set this flag in the following ways:
- Use the Windows Firewall with Advanced Security snap-in (within the Group Policy object). Obtain properties of an inbound rule, click the Advanced tab, and then select Allow edge traversal in Edge traversal.
- Use the edge=yes option for the netsh advfirewall firewall command when adding or changing an inbound rule.
For a computer that is being managed to be reachable over Teredo, ensure that the computer has an inbound ICMPv6 Echo request allow rule with edge traversal enabled. The Netsh.exe command for this rule is the following:
netsh advfirewall firewall add rule name="Inbound ICMPv6 Echo request with Edge traversal" protocol=icmpv6:128,any dir=in action=allow edge=yes profile=public,private
Here is an example of how a Remote Desktop rule with edge traversal can be enabled using a Netsh.exe command:
netsh advfirewall firewall add rule name=”remote desktop” profile=public,private dir=in program=system action=allow protocol=tcp localport=3389 edge=yes remoteip=<Corp v6 range>
To further ensure that the remote desktop connection is authenticated and encrypted, add the following rule, which uses the security keyword
netsh advfirewall firewall add rule name=”remote desktop” profile=public,private dir=in program=system action=allow protocol=tcp localport=3389 security=authenc edge=yes remoteip=<Corp v6 range>
To use this setting, you need to ensure that there is a transport mode IPsec policy that secures the connection between the management server and the client.
| Note |
|---|
| If the computer that is managing a DirectAccess client from the intranet is running Windows Vista or Windows Server 2008 and IPsec transport mode is required between the managing computer and the DirectAccess client, both computers must have the same quick mode lifetimes. |
If your DirectAccess policies are configured using server names instead of IP addresses, the Teredo server, 6to4 Relay, and IP-HTTPS server names must all be resolvable from the public Internet namespace. These servers may all be physically located on the same server, in which case only a single name needs to be made available. If these server names are not resolvable from outside your organization, DirectAccess users will not be able to connect from the Intranet.
As an alternative, DirectAccess policies can be configured using IP addresses for the Teredo server, 6to4 Relay, and IP-HTTPS server, in which case these server names do not need to be publicly resolvable.
| Note |
|---|
| By default, the DirectAccess Setup Wizard configures the 6to4 relay and the Teredo server with an IPv4 address and the IP-HTTPS server with an FQDN. |
Depending on the application being used, DirectAccess clients can communicate directly with other DirectAccess clients, even when outside of the intranet. Applications that allow clients to connect directly from one to another are broadly referred to as Peer-to-Peer (P2P) applications.
Many P2P applications provide their own built in security, such as Groove or Office Communicator. Some applications do not provide any additional security. Remote Assistance, Remote Desktop, and File and Printer Sharing are in this category. By leveraging IPsec, DirectAccess allows these applications to communicate securely even when they lack their own security mechanisms.
To secure connectivity for specific applications:
- Create an IPsec transport mode rule and associated firewall rules for each application you wish to secure using the following general policy guidelines: Transport mode, RequestinRequestout, Non-Corp v6 <=> Non-Corp v6 , Auth = Computer certificate, Profile=public, private
- Create Windows firewall rules for each application. For example, for Remote Desktop, the Windows Firewall rule would look like the following: Profile= Public, Private; Program = c:\windows\system32\mstsc.exe; Allow if secure + encryption; Inbound; TCP 3389
To configure the IPsec rule using Netsh.exe, you can use the following format:
netsh advfirewall consec add rule endpoint1=<Non-Corp v6> endpoint2=<Non-Corp v6> action=requestinrequestout profile=public,private auth1=computercert auth1ca=<CA Name>
To configure the Windows Firewall rule using Netsh.exe, you can use the following format:
netsh advfirewall firewall add rule name=”remote desktop” profile=public,private program=system action=allow security=authenc protocol=tcp localport=3389
Finally, additional security can be configured to prevent communication between DirectAccess clients unless the traffic is secured. This is accomplished by modifying the action on the connection security rule for action=requireinrequestout, which will result in the host dropping any connections from IPv6 hosts that are not encrypted.
Outgoing connections to other DirectAccess clients will be secured regardless of the application. Outgoing connections to Internet and non-DirectAccess clients will result in successful unprotected communication.
To increase the number of concurrent authentication calls in progress at one time between the DirectAccess server and the domain controller, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ MaxConcurrentApi (REG_DWORD) registry value to 5, and then restart the NETLOGON service.
If you do not specify management servers, there are two IPsec tunnel mode rules in a default DirectAccess configuration as configured by the DirectAccess Setup Wizard:
- The first tunnel is from the DirectAccess client to the DirectAccess server to support access to the IPv6 addresses of DNS servers and AD DS domain controllers.
This tunnel uses Computer certificate credentials for the first authentication and User (NTLMv2) for the second authentication. User (NTLMv2) credentials are used to force the use of AuthIP and because the DirectAccess client needs DNS and domain controller access before it can use Kerberos credentials for the second tunnel. - The second tunnel is from the client to the DirectAccess server to support access to the IPv6 address space of the intranet.
This tunnel uses Computer certificate credentials for the first authentication and User (Kerberos V5) for the second authentication.
Additionally, IPsec tunnel mode settings can be used to require smart card-based authorization for remote users by the DirectAccess server. This IPsec tunnel authorization can be used specifically to require smart cards for remote DirectAccess connectivity. IPsec authorization is an extended setting on IPsec tunnels that enforces authorization for specific computer or user security groups by enforcing the existence of a specific Kerberos-related security identifier (SID) that is generated when a user logs on with a smart card.
IPsec authorization for requiring smart cards should only be configured on the tunnel that is used to provide access to the intranet (the second tunnel previously described), not on the tunnels that are used for DNS and domain controller or management server access. DirectAccess clients require access to the core domain infrastructure to validate their credentials, including their smart card credentials. These credentials are then used to gain access to the rest of the intranet using the second IPsec tunnel.
To use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment and client smart card infrastructure.
After the PKI and smart card infrastructure is in place, you add global IPsec tunnel mode authorization settings to the Group Policy object for the DirectAccess server, specifying the authorization identifier for smart card logons.
The way smart card enforcement works with IPsec authorization is that IPsec can be configured to look for specific Kerberos-based SIDs in a client’s Kerberos token. IPsec is configured to enforce Kerberos-based user authentication and is also configured to look for specific authorized users. For smart card enforcement, the authorized user is actually a well-known SID (S-1-5-65-1) that maps to smart card-based logons. This SID is referred to as “This Organization Certificate” when it is configured in the global tunnel mode authorization settings.
When smart card authorization is enforced at the edge by using an IPsec authorization policy and a user logs in without a smart card, a message displays in the notification area. The following figure shows an example:
Users can click this message and provide their smart cards and PINs to gain access to intranet resources.
You can require users of DirectAccess client computers to provide their smart card credentials before allowing access to intranet resources by selecting the Require smart card login for users check box on the Connectivity page of Step 2 of the DirectAccess Setup Wizard. The following figure shows an example:
The following figure shows an example of the global IPsec tunnel mode authorization setting when you select the Require smart card login for users check box in the DirectAccess Setup Wizard.
To view this dialog box in the Windows Firewall with Advanced Security snap-in, do the following:
- Right-click Windows Firewall with Advanced Security, and then click Properties.
- On the IP Settings tab, in IPsec tunnel authorization, click Customize.
- Click the Users tab.
To perform the equivalent configuration of the DirectAccess Setup Wizard with the Netsh.exe tool, use the following commands:
netsh advfirewall consec add rule name=”Smart card tunnel” endpoint1=Intranet IPv6 address space endpoint2=Any localtunnelendpoint=DirectAccess server IPv6 address 2 remotetunnelendpoint=any auth1=Computercert auth1ca=”Certificate Auth name certmapping:yes” auth2=userkerb applyauthz=yes
netsh advfirewall set global ipsec authzusergrp=O:LSD:(A;;CC;;;S-1-5-65-1)
If you need to lock out a DirectAccess client and prevent it from making DirectAccess connections, you can do so by disabling the computer account in Active Directory. This is the recommended method.
Another method is to enable strong CRL checking for IPsec and then revoke the DirectAccess client’s certificate, preventing authentication with the DirectAccess server. Strong CRL checking is not enabled by default; if you revoke a computer certificate of a DirectAccess client, it will still be able to make authenticated connections to the DirectAccess server.
To enable strong CRL checking for IPsec authentication, use the following procedure:
- On the domain controller, run the following commands:
netsh adv set store gpo=[domain name]\[GUID for the DirectAccess server GPO]
netsh adv set global ipsec strongcrlcheck 2 - On the DirectAccess server, use the gpupdate /target:computer command to update computer configuration Group Policy settings.
| Note |
|---|
| If you enable strong CRL checking and the DirectAccess server cannot reach the CRL distribution point, IPsec authentication for all DirectAccess connections will fail. If you are using NAP and health certificates and you enable strong CRL checking, IPsec authentication for all DirectAccess connections will fail. Health certificates do not have CRLs because their lifetime is typically on the order of hours, instead of years for typical computer certificates. |
Set the Group Policy setting for Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Turn on automatic detection of the intranet to Disabled. This disables the ability of Internet Explorer® to leak NTLM credentials by default when single-label names are used. You can set the setting in the Group Policy object (GPO), never prompt, to prevent NTLM from being used in the Internet or Local Intranet Zone entirely. List the known intranet sites in the Trusted Sites Zone.
Enable the setting to prevent elevation to Local Intranet Zone from Internet Zone.
Subscribe to:
Posts (Atom)