UAG DirectAccess Deployment using NAT64 and DNS64

Part 1 : UAG DirectAccess Configuration using the NAT64 and DNS64 – Certificate Authority Configuration

Part 2 : UAG DirectAccess Configuration using the NAT64 and DNS64

Part 3 : UAG DirectAccess Configuration using the NAT64 and DNS64

Cheers !!!

Microsoft DirectAccess Considerations when implementing it using Windows 2008 R2 based DirectAccess or using the Forefront Unified Access Gateway 2010 based DirectAccess (UAG DA)

Many a times I have been asked this question, what are the key considerations of implementing the DirectAccess Connectivity? Seriously, there are quite many. I am trying to put together few of them and will keep updating as and when I will come across.

 

1. When using the ISATAP connectivity internally, DirectAccess clients can only communicate using applications that support IPv6 and connect to intranet resources that are reachable with IPv6.
2. IPv4-only client applications will fail to connect over DirectAccess even using the NAT64 through UAG DirectAccess Server.
3. Native IPv6 on intranet is required for Bi-Directional Connectivity. NAT64 does not support bi-directional connectivity.
4. Windows Vista and above support native IPv6, however only Windows 7 machines can initiate the DirectAccess connectivity.
5. Windows XP and Server 2003 have an IPv6 stack, but built in system services are not IPv6-capable which means the Windows XP/2003/2000 machines cannot be accessed over DirectAccess when using the ISATAP internally. They can only be accessed when using the NAT64 or a NAT-PT device (non-Microsoft devices)
6. Windows 7 machines connecting over DirectAccess should be domain joined, logged in with domain credentials and should be either Ultimate or Enterprise edition.
7. Optionally, Conventional VPN connectivity may still be required for GPO update for first time.
8. End-to-End IPsec Authentication is not supported when using the NAT64
9. In some scenarios the internal infrastructure may need an upgrade depending on the type of configuration. Like, routers which do not do IPsec forwarding should be upgraded when using End-to-End Connectivity.
10. In Server/Client application, the server side does not need to be IPv6 when implementing NAT64, but the client side application should be IPv6 aware when communicating. It will fail to connect otherwise.
11. Some client side applications are written to use the server’s internal IPv4 address to connect.While installing or after installation these client applications uses the IP address to locate the server. When this kind of application tries to connect over DirectAccess connectivity, it will FAIL. IPv4 traffic cannot be passed through the DirectAccess tunnel. Meaning, any such application will not work over DirectAccess. It requires either a client version which support IPv6 or you need the SSTP connector in UAG to create a VPN tunnel when using that application.

Cheers !!!

Windows Server 2008 R2 DirectAccess Error: Registration of ISATAP in DNS Failed

I recently came across this error while configuring the Windows Server 2008 R2 based DirectAccess Server. Below is the configuration we had;

Windows Server 2003 Based Active Directory with Windows Server 2003 Domain Controller and DNS
Additional Windows Server 2008 R2 Domain Controller with DNS to push DirectAccess Policies
Windows Server 2008 R2 DirectAccess Server

When we applied the DirectAccess script from within the DirectAccess MMC console, it gave us the following error.

We later discovered that the default domain Administrator account was renamed to “Adminuser” and proper permissions were not being assigned to this user. We are still investigating the cause but the workaround is to assign this user permissions on the following

1. Windows Server 2008 R2 DNS Server
2. ISATAP A host record in the DNS if it has been manually created

Re-run the script and the script should run without errors

Cheers !!!

UAG Team Blog: DirectAccess Resources

Deep Dive Into DirectAccess – NAT64 and DNS64 In Action
http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx

Deep Dive Into DirectAccess
http://blogs.technet.com/edgeaccessblog/archive/2009/08/27/deep-dive-into-directaccess-part-1.aspx
http://blogs.technet.com/edgeaccessblog/archive/2009/08/27/deep-dive-into-directaccess-part-2.aspx 

Deep dive into UAG DirectAccess (IPv6 and DirectAccess)
http://blogs.technet.com/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx

Deep dive into UAG DirectAccess (Certificates)
http://blogs.technet.com/edgeaccessblog/archive/2009/10/27/deep-dive-into-uag-directaccess-certificates.aspx

Deep dive into UAG DirectAccess (Manage Out Basics)
http://blogs.technet.com/edgeaccessblog/archive/2009/11/17/deep-dive-into-uag-directaccess-manage-out-basics.aspx

 

Cheers !!

UAG DA Error: Failed: Cannot create a file when that file already exists

 

I recently came across this error while working on a UAG DirectAccess deployment in a customer test environment. This error is generated when we apply the policy (.PS1) script created by UAG. This error will still come if you try to execute the PS1 script from the PowerShell Command prompt.

The cause is yet to be known. We got to the bottom of the issue with the help of a Software Developer in UAG team. The problem is caused when the script is unable to remove or modify the Da.wfw file which is ceated under the %userprofile%AppDataLocalTemp folder.

 

The workaround of this problem is as below:

1. Create a C:temp folder
2. Export the PS1 script after you make the modification to the UAG DA Configuration
3. Open the script in Notepad. Leave the first three lines (as shown in below image) and enter a cmdlet as $env:temp = c:temp
4. Save the File
5. Open the PowerShell Command Prompt and run the PS1 script you modified in step 3
6. Open the regular command prompt with Administrative privileges and run GPUPDATE /FORCE 
7. Check the GPOs and it should have now been created

** The UAG product team is still investigating the cause of this issue

The above mentioned steps have to be done every time you make a change to the UAG Server configuration.

***Update**********************************

Date: 1/20/2010

From further investigation it seems like that this issues is caused in scenarios where you are using an admin account with a dot (".") in the username like david.smith or firstname.lastname. Workaround is to use an admin account without a dot (".") in the username. Just a FYI, the concerned teams are looking into the matter and will come up with a fix or the documentation soon (no timeframe yet)

*******************************************

Cheers

UAG DirectAccess Activation failed with the following error: Cannot create a file when that file already exists. The error occurred on object ‘AddressRanges’ of class ‘AddressRanges’ in the scope on Array ‘UAG’

 

This error is caused due to an unusual behavior by UAG which is being investigated by the product team. This error is caused when UAG unexpectedly adds the Address Range network objects “Anywhere(IPv6)” and “DirectAccess Local DNS” in to the System policy rule # 11 “Remote Management: Allow ICMP (PING) requests from selected computers to Forefront TMG” of Microsoft Threat Management Gateway Server 2010 (TMG 2010).

Threat Management Gateway 2010 is an application layer firewalls which sits beneath UAG and protects the UAG server and the traffic coming into the network.

At this point I am not sure what may have caused the issue but by removing the above Address Ranges from the rule # 11 I was able to Activate my DirectAccess configuration

I will update the blog entry once I know the exact cause of the problem.

Till then..Cheers

Configuring UAG DirectAccess

 

*** Only tested the below configuration with 6to4 and Teredo ***

UAG DirectAccess provides many other benefits which Windows 2008 R2 DirectAccess does not provide by default, like: NAT64 and DNS64 which helps to communicate with IPv4 only machines such as XP and Windows 2003. Using the UAG DirectAccess you can now provide one stop remote connectivity solution without any major changes in your internal environment.

I tried configuring the UAG DirectAccess and faced a lot of challenges initially. So, I thought it would be wise to write a blog on how to configure the UAG DirectAccess.

I assume that you have already installed the UAG on a Windows 2008 R2 machine.

First, you need to create a security group in your current AD (no need to change the AD to Windows 2008/R2 for DirectAccess. You may use your Windows 2003 AD). Add the Windows 7 ultimate/enterprise laptops which will connect remotely using the DirectAccess functionality to this security group. Now, click the first step in under the DirectAccess console and add the security group which we created.

Second, You need to assign a /96 bit IPv6 address to the internal interface of the UAG Server. Assign Two publicly routable IPv4 addresses on the external NIC of the UAG Server.

Third, click on the step 2 on the DirectAccess console and define the internet-facing and internal network. If you want UAG to use the NAT64 and DNS64 when communicating with IPv4 machines then you need to select the IPv6 address you assigned in the previous step. If you have internal machines capable of the holding IPv6 addresses then you may skip the previous step.

Then Click Next.

Next, you need to enable the NAT64 and DNS64. Click Next

Next, assign a /48 bit prefix for your organization. For more information check http://blogs.technet.com/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx

Next, select the Root CA and the Server Authentication certificate to be used by the IP-HTTPS. Click Finish

Fourth, click step 3 and define the URL for the Network Location Server. This server helps the DirectAccess client machines to determine whether they are on internal network or external network.

Click next

Next, provide the DNX suffix for your organization. Provide all DNS Suffixes if you have different domains and exclude the UAG’s FQDN and the NLS Server from the NRPT (Name Resolution Policy Table)

Add the IP/Prefix for the DC and the management servers.

Fifth, click step 4 and define how the users will be authenticated. For more information check http://technet.microsoft.com/en-us/library/dd637823(WS.10).aspx and http://technet.microsoft.com/en-us/library/dd857232.aspx

Click Finish

At Last, click Finish and Apply the changes. the changes will create appropriate group policies in the Active Directory domain. Windows 7 client machines which will use the DirectAccess Connectivity, they should get these policies at least once to connect.

Active the UAG configuration to make the configuration work properly.

Windows Server 2008 R2 – DirectAccess

Things to consider before deploying DirectAccess Server

1. Identify applications which support IPv6.

This is important because the communication between Server and Clients using DirectAccess happens on IPV6 unless you are using NAT-PT devices to translate IPv6 to IPv4 and vice versa. The applications which don’t understand IPv6 will not be able to communicate over DirectAccess.

2. Identifying the applications which you want DirectAccess users to access.

This is important and goes hand in hand with the first point. You may want the users to access particular application but that application may not be compatible with IPv6 OR there are so many applications which support IPv6 but you don’t want users to access everything from DirectAccess. Planning the access initially reduces considerable amount of time.

3. Windows 7 deployment across the organization or at least for the machines participating in DirectAccess.

Because DirectAccess is only supported by Windows 7 client machines so, it because necessary to plan the deployment of Windows 7 on workstations / Laptops especially which are always Mobile.

4. Setting up of Certificate Authority if not already existing.

There can be multiple ways to authenticate the client machines to come through the DirectAccess. You may use the machine certificates, Kerberos and / or Smart card authentication. Since, DirectAccess inherits the IPsec capabilities you would require machine certificates to negotiate the communication between clients and the DirectAccess Server.

5. At least one domain controller to be either Windows Server 2008 or Windows Server 2008 R2

Since Windows 2003 server does not support IPv6 completely, you would need one of your Domain Controllers and DNS Servers to be Windows Server 2008 or 2008 R2 so to fully support IPv6.

6. Implementing IPSec Policies and managing the encrypted traffic

IPsec is a baseline security model for protecting the traffic to and from the DirectAccess server and client machines. Check http://technet.microsoft.com/en-us/library/dd637836(WS.10).aspx for more information on Choosing the right model for the DirectAccess.

7. Two consecutive public IP addresses to be assigned to the DirectAccess Server’s external interface connected to the internet

This additional requirement is actually imposed by the Teredo Service (one of the transition technologies for IPv6) and not directly by the DirectAccess Server. Check the RFC at http://www.ietf.org/rfc/rfc4380.txt