Secure Endpoint: DirectAccess and Microsoft Forefront Unified Access Gateway 2010, the Complete Remote Access Solution
Spend an hour learning about Microsoft's complete remote access vision and how UAG and Direct Access Technology together provide seamless remote access to users while reducing IT risks and costs. This session includes a live demonstration of the features and the remote access solution in action
http://www.msteched.com/2010/NorthAmerica/SIA301
End-to-End Remote Connectivity with DirectAccess
DirectAccess is a new feature in the Windows 7 and Windows Server 2008 R2 operating systems that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess, users are able to access corporate resources (such as email servers, shared folders, or intranet Web sites) securely without connecting to a virtual private network (VPN). This chalk talk addresses questions on setup and troubleshoots a DirectAccess infrastructure
http://www.msteched.com/2010/NorthAmerica/WSV207
HTH,
Tom
Tom Shinder tomsh@microsoft.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
I hear a lot of folks talking about deploying DirectAccess as a replacement for their current VPN solution. They often want to move large numbers of their users from working at the office to home offices. This is a great idea, as it saves on the infrastructure costs related to heating and cooling offices, fuel costs related to driving back and forth to work, and ideally increase the employees overall productivity because they could use the time they were driving to work to actually get work done.
That’s all consistent with the goal of DirectAccess – to provide your users an intranet computing experience from anywhere in the world. And when I speak of “users” I’m not just talking about end-users - “users” also include IT, as your IT group will be able to have the same connectivity to, and command and control over, DirectAccess clients as they have with any other client they manage on the intranet today.
When talking to people about DirectAccess, it’s best to not think of DirectAccess as a “VPN” solution – since the vision of DirectAccess is to keep the DirectAccess client continuously connected to the intranet – thus bringing the intranet “out” to all DirectAccess clients. In contrast, VPN connections (SSL and network level) are about temporary connectivity that enables the VPN client “into” the intranet. It might seem like hair splitting, but the practical implications are significant, both from the end-user productivity perspective and the IT management and control perspective.
Because this vision is all about highly managed corporate controlled systems, you still might want to provide VPN access for machines that don’t fit into this vision. You might need to enable partners full network access at times, or perhaps the IT group needs VPN access from unmanaged machines of their own to get work done when out of the office. In this scenario, the DirectAccess and VPN solution can site side by side, or if your VPN clients support SSTP as a remote access VPN protocol (clients are Windows Vista SP1 and above), you can co-locate the SSTP VPN server on the DirectAccess server or array.
So when carrying out your DirectAccess deployment planning, remember that VPN is something that you’ll want to bake into the overall remote access solution.
That's a good question. But before we go there, we have to think about connectivity between the DirectAccess server and the DirectAccess client. The DirectAccess client always communicates with the DirectAccess server using IPv6. There is no IPv4 application traffic moving between the DirectAccess client and DirectAccess server. This means that the client side applications running on the DirectAccess client must be IPv6 aware.
On the server side it doesn't matter - you can run IPv4 only server applications on an IPv6 capable operating system, or you can run IPv6 aware server applications on an IPv4 only operating system. IPv4 isn't an issue when using UAG DirectAccess, because we have the DNS64/NAT64 feature to support IPv4 communications between the DirectAccess server and the destination server on the intranet. There are some exceptions to this, such as not being able to initiate a connection from an IPv4 only server or server application to a DirectAccess client, or when there are “call-backs” required or when there are addresses imbedded in the application protocol, but for the most part the IPv4 only server application will not be a problem.
This means that if your client side applications don't support IPv6, you're going to have to think about a solution. Some things to consider include:
Something that I want to make clear is that if you are running into problem with your client-side applications, we’re here to help you. We’ve helped customers get some applications working with DirectAccess that at first didn’t seem to work. If you want to deploy DirectAccess but are facing a difficult application that doesn’t seem to work with DirectAccess, we want to know about your problem and see if we can help you solve it. Please contact me at tomsh@microsoft.com and I will put you in contact with the team who can help you move forward in helping to solve the application issue.
There is one important issue that you should be aware of, and this relates to those organizations that plan on using Force Tunneling. By default, UAG DirectAccess (as well as the Windows DirectAccess) enables a form of split tunneling, by virtue of the fact that requests for non-intranet resources are sent directly to the Internet server, and not tunneled through the DirectAccess links to the DirectAccess server and out through the corporate firewall or proxy.
Some IT groups are hesitant to support split tunneling based on assumptions made during the 1990s regarding VPN client behavior and the nature and capabilities of malware at that time in history. The networking and threat management landscape is very different now and issues that we're important in a split tunneling configuration 15 years ago are no longer extant. However, not all IT groups have caught up with this or have their hands forced by other decision makers, and therefore may choose to disable the split tunneling configuration by enabling Force Tunneling.
If you do enable Force Tunneling, be aware that all communications will be sent through the DA tunnels. This means you will not have the option to use a Internet facing proxy or relay for your non-IPv6 compliant client applications and you will not be able to fall back to using an SSTP VPN, PPTP VPN, L2TP/IPsec VPN, or even an SSL VPN.
The decision to use Force Tunneling should be made with the knowledge that all your client side applications must be IPv6 aware - as they will not be able to use any fall back mechanism that requires them to connect to the Internet.
(Updated July 21, 2010)
Interesting post on the TechNet forums regarding problems with configuration.exe:
“I currently have a working DirectAccess single server UAG deployment (using at trunk as well). It is working fine and i have updated the deployment to Update roll-up 1.
I am due to demo to a client DirectAccess with UAG and they are also interested in using NAP. So I have built and deployed a NAP server, but now every time I try to change any of the settings in UAG for the "DirectAccess Server" component the console hangs (50% CPU) and i have to kill configuration.exe .... I get this no matter what i edit on the last stage of that screen (i.e smart card auth, certificates etc... it literally hangs the second I click anything!).
I have tried running a procmon trace but without much insight, I've also made sure i disabled any Anti-Virus on the server.”
http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/45a79cc3-da73-460a-a267-6a0d8e59c6a3
===============================
The solution to the problem is to run:
C:\Program Files\Microsoft Forefront Unified Access Gateway\utils\ConfigMgr>configmgrutil -del -
and give it another try.
WARNING: Be aware that executing this command will delete the entire UAG configuration, including DirectAccess configuration and trunks, and you will need to reconfigure your UAG server manually to its previous configuration. If you have an uncorrupted backup you can restore the configuration from backup.
Apparently, this happens when you select an Intermediate Certificate Authority on the NAP configuration (checkbox) page. You can’t use an Intermediate Certification Authority for IPsec (with UAG, at least at this time).
There is also an issue with NAP enforcement with the RTM version of UAG, so make sure you upgrade to UAG Update 1.
Tom Shinder tomsh@microsoft.com Microsoft ISD iX/SCD iX UAG Direct Access/Anywhere Access Team The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder