UAG 2010 addresses many of the shortcomings of DirectAccess
Microsoft’s Forefront Unified Access Gateway 2010 addresses many of the shortcomings of the company’s new always-on remote connectivity solution, Direct-Access, providing sorely needed measures of performance and availability scaling, global management and backward compatibility to help move Direct-Access beyond mere pilot projects to actual deployment on real networks.
I tested DirectAccess last October, (tinyurl.com/yelgw6m) and found that the product (which is baked into Windows 7 Enterprise and Ultimate on the client side, as well as Windows Server 2008 R2) made for an interesting and effective pilot project. However, its lack of scale, global manageability and backward OS compatibility on both the client and server sides would effectively limit its usefulness on most live domains and networks. Into the breach steps UAG, which addresses each of those concerns. Administrators who install
UAG on each DirectAccess server in the network can scale DirectAccess management and performance beyond a single server by creating an array to aggregate all the servers. UAG’s NAT64 and DNS64 implementations provide DirectAccess connectivity to IPv4-only intranet servers and applications, while SSL (Secure Sockets Layer) VPN functionality provides access to remote clients using older operating systems or those not joined to the domain. For the purposes of this test, I focused on the enhancements to DirectAccess that UAG affords, and did not look at UAG’s SSL VPN implementation. Forefront UAG 2010, which started shipping in December, is licensed through Microsoft’s volume licensing program and requires both preserver licenses and CALs (Client Access Licenses). Each Forefront UAG server license costs $6,341 (which does not include the license cost for the underlying Windows Server 2008 R2 OS), while CALs (which can be purchased per user or per device) are $15 each. Large customers ordering more than 10,000 access licenses are eligible for a volume discount.
Making use of IPv6
On its own, DirectAccess makes use of IPv6 to route traffic from a remote Windows 7 client over the Internet to the DirectAccess server that bridges the traffic to a protected intranet server. IPv6 support is incomplete throughout the Internet, so Direct- Access employs transition technologies such as 6to4 and Teredo to traverse the IPv4 Internet or NAT (Network Address Translation) networks. But if the intranet server doesn’t support IPv6 with a dual-layer IP stack, DirectAccess can’t complete the connection. Forefront UAG 2010 solves this problem by implementing NAT64 and DNS64 at the network edge. When a remote client tries to access an intranet server, UAG sends two DNS (Domain Name System) lookups to the intranet DNS server—one for an IPv4 A record and one for an IPv6 AAAA record. If the DNS server has both records, it will return the AAAA record to UAG, and standard DirectAccess communications will be employed. If an application does not support IPv6 while the server itself does, administrators should disable the IPv6 support on the server or remove its AAAA record from DNS to avoid complications.
If only an A record gets returned, UAG assumes the server uses only IPv4, and NAT64 must be employed. NAT64 adds a prefix to the server’s IPv4 address and returns the full value (prefix plus IPv4 address) to the requesting client. When the client begins communications with the server, UAG strips off the prefix and creates a new IPv4 packet to send to the server. When the server responds through the same UAG gateway, UAG recrafts the packet for IPv6 with the prefix and sends it to the client. To test UAG’s ability to deliver DirectAccess connectivity to legacy applications and servers, I added a Windows Server 2003-based member server running Exchange 2003 to my test network. Although Windows Server 2003 does support IPv6, it has a dual-stack IP implementation that doesn’t work with DirectAccess.
Through UAG, my remote client was able to access Exchange as if the machine were connected directly to the intranet. I was able to connect to Outlook Web Access and to Exchange from Outlook without needing to change settings on the client. I also tested UAG’s DirectAccess functionality with a non-Microsoft Web application. I added an old firewall appliance that doesn’t support IPv6 to the intranet and added the appropriate A record to my DNS server. Again, from my remote client, I was able to successfully access the appliance’s Web-based management console via UAG DirectAccess. For my tests, I deployed UAG DirectAccess in an end-to-edge configuration, terminating encryption and authentication at the UAG server at the network edge.
Load balancing
Forefront UAG 2010 allows administrators to scale the management and performance of DirectAccess, which, by itself, requires administrators to individually configure each Direct- Access server. UAG allows administrators to define one UAG DirectAccess server as an array master, effectively replacing the DirectAccess management snap-in with a UAG snap-in, through which a policy created on the master will be automatically replicated to all member servers in the array.
When I added a second UAG server, I used Windows’ built-in Network Load Balancing technology. I had to define virtual IP addresses (one on the intranet and two on the Internet) to represent the cluster; create a certificate for the VIP; and ensure a certificate was exported to the store on each UAG server. With two servers in my UAG array, from my remote client I initiated a connection to my Exchange server on the intranet. By looking at certificate information on the client, I determined which UAG server in the array was parsing the connection. I paused that UAG server’s virtual machine, simulating a server failure.
After a minute, the connection failed over to the second UAG server, re-establishing the connection between the remote client and Exchange server. The delay is due to a
60-second wait period before Windows will break an IP Security association. This delay is put in place to avoid excessive IPSec negotiations with clients on lousy network connections, but the wait period can mean a minute-long lack of remote connectivity that could lead to some support calls.
Although the IPSec timeout is not configurable, Microsoft officials have said there are programmatic workarounds that can be done on the client end to break the connection. If this timeout becomes an issue for customers, they said, Microsoft will look into providing a fix to do that.
Source of Information : eWeek February 15 2010
No comments:
Post a Comment