Troubleshooting is always a challenging topic. Challenging from the point of view of the person who has to do the troubleshooting, and challenging to the product group who wants to provide valuable troubleshooting information so that you can solve your troubleshooting issues.
Because information on troubleshooting is so dynamic, we need a way to share information on what we learn about troubleshooting as soon as possible. For this reason, we’ve decided to publish UAG DirectAccess troubleshooting information to the TechNet wiki. With the TechNet wiki, we can provide you “just in time” information about how to troubleshoot problems you might encounter with UAG DirectAccess.
And even more important, if you find that you have a valuable troubleshooting information that will help other UAG DirectAccess admins, you can share that information on the TechNet wiki!
As we begin this effort, we’ve created a main UAG DirectAccess troubleshooting page – Forefront UAG DirectAccess Troubleshooting. On this page you will find useful links to UAG DirectAccess troubleshooting content. Right now, you’ll find links to the following wiki docs:
The great utility of the wiki is that if you find other UAG DirectAccess troubleshooting information, you can add to this list – as another logged onto the wiki can edit and enhance the content. Make sure to add the RSS feed for this page so that you receive automatic updates when this troubleshooting page is updated.
HTH,
Tom
Tom Shinder tomsh@microsoft.com Knowledge Engineer, Microsoft DAIP iX/Forefront 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
(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
“All our times have come Here, but now they’re gone Seasons don’t fear the reaper Nor do the wind, the sun or the rain (We can be like they are) Come on baby (Don’t fear the reaper) Baby, take my hand (Don’t fear the reaper) We’ll be able to fly (Don’t fear the reaper) Baby, I’m your man….”
Listen to 30 seconds of the song here (play #3)
OK, enough of the Blue Oyster Cult, let’s get down to business.
Whenever I introduce people to DirectAccess, I start with all the great things it has to offer. IT gets to control and manage the DA clients on the Internet in the same way they control and manage clients that never leave the corpnet. End users get to connect to what they need on the corpnet without having to think about it. Everyone is happier than ever and this is what IT and end users have been waiting for, what everyone really was expecting of remote access since the first dial-up connection was made way back in the 20th century.
After the troops get charged up about what DirectAccess has to offer, I get to the foundations of the solution. I start with Windows Firewall with Advanced Security. OK, that’s cool, we’ve all worked with host-based firewalls and that’s no problem. Then I get to IPsec. Hmmm. That’s a little scary, but then, most of us have used IPsec for L2TP/IPsec connections, and some of us have even used it to connect VPN gateways using site to site IPsec tunnel mode connections. So while a little scary, IPsec isn’t a deal breaker. DNS? No problem! How about creating SSL web sites? Again, total no brainer. Certificates and PKI? Sometimes problematic, but putting together a PKI and issuing certificates is pretty mainstream these days, and DirectAccess doesn’t impose any “off-label” type of certificate requirements, just everyday computer and web site certificates. So even when PKI is on the table, DirectAccess is still looking like a might juicy proposition.
Then I say “IPv6”
Jaws drop, eyes glaze over, smiles turn to frowns, elation turns to desolation, and the entire upbeat nature of the conversation turns into a something akin to a funeral procession.
When that happens, I’ve got to turn things around fast, or else it it’ll turn from “Don’t fear the reaper or IPv6” to “you’ve lost that lovin’ feelin”. The good news is that when you deploy DirectAccess using UAG, you don’t need to fear IPv6 (and maybe the reaper too).
I understand the trepidation involved with IPv6. A lot of companies have already decided that there is little to gain from IPv6, and that it’s unlikely that we’ll see widespread adoption of IPv6 on the Internet in our lifetimes. So why deal with what looks like a complicated mess of 128 bit numbers that are impossible to remember and a new addressing scheme that makes IPv4 look like child’s play?
True, DirectAccess uses IPv6 communications as it’s foundation. All communications from the DA client to the UAG DA server are IPv6. This means that the client application on the DA client must be IPv6 aware. However, the server doesn’t need to be IPv6 aware, because UAG has a few tricks up its sleeve to make it all work.
In fact, the UAG DA server has enough technology built right in so that you can completely avoid any understanding of IPv6 and still get DirectAccess working on your network. Now, I’m the last guy in the world who would advocate that you should know nothing about the basic underlying networking technologies that run your solution. And I bet that once you get into the DirectAccess game, you’ll want to dig into IPv6 a little more. What you’re really concerned about is having to become an “IPv6 networking jockey” and end up in a 4 year long course of study on IPv6 before even getting started on DirectAccess.
As we say here in Texas “that dog don’t hunt”
And we don’t need that dog to hunt. Here are some of the technologies used by UAG DirectAccess that allow you to put some skin in the DirectAccess game without putting on an IPv6 propeller cap:
There you go. IPv6 for the UAG DA admin. The point is that you need to know very little if anything about IPv6 to get a production ready UAG DA server up and running. Will you benefit from getting to know some about IPv6? Sure, as you’ll understand what’s going on in the background and you can be more flexible in your deployment. Will you benefit from being an IPv6 jock? You bet! When you reach that level of sophistication you can start thinking about moving your corpnet into native IPv6, and use IPv6 aware routers, switches, NIDS and the rest. Knowledge is always power, but UAG DA already includes quite a bit of power on its own so it spares you from the rigors of intimate (or even passing) knowledge of IPv6.
So don’t fear IPv6. The seasons don’t fear IPv6, nor does the sun nor the wind nor the rain. You can be like they are! However, since 98%+ of you reading this are probably men, I’m not going to call you “baby” and I’m not “your man” :)
I’ll talk more about IPv6 concepts in the future on this blog and also in some guides I’m planning on putting out that will provide you with some “kissing cousin” familiarity with key UAG DA IPv6 concepts. Not enough to blow your mind, but enough where all the pieces will fall into place quickly so that you’ll maybe get jazzed enough to look into IPv6 a bit more when you have the time.
Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX\Anywhere Access Team
UAG DirectAccess
I’m thinking of putting together a Test Lab Guide module for configuring end-to-end security for UAG DirectAccess clients and selected application servers on the intranet, so I configured the scenario in the Test Lab to see how it worked. I figured that since everything is working in the Test Lab now, I should take some time to share with you what end-to-end security looks like when you configure it using the UAG DirectAccess wizard.
If you want to follow along with what I’m describing in this blog post, you can fire up your UAG DirectAccess lab if you have a snapshot handy. If you haven’t completed the UAG DirectAccess lab yet, then you might want to download the Test Lab Guide: Demonstrate UAG DirectAccess (http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c243c30c-6476-4061-9520-124710dbdd27) and you can get a snapshot saved. Then you can see how the same things I describe in this blog post in your own Test Lab.
Before I go into the details, it’s worth going over some basic UAG DirectAccess concepts. UAG DirectAccess supports two types of network security access models:
Note that ESP null encapsulation is different than (ESP)-NULL. With null encapsulation only the first packet of the connection is authenticated, so that the remainder of the communications are available to the IDS for inspection. For more information on this subject, see http://technet.microsoft.com/en-us/library/ee382325(WS.10).aspx
Also, if you want to do end-to-end security, the server on the intranet needs to be IPv6 capable, which means it has a native IPv6 address or an ISATAP address. This essentially limits your servers to being Windows Server 2008 and above, although there products available that you can use to enable non-Microsoft servers to participate end-to-end IPsec security, but I won’t go into those methods today.
If you want to enable end-to-end security, you’ll need to assign the intranet servers to groups that can be used by the object-picker used in the UAG management console. You can use existing groups if you like, but in most cases you’re probably better off creating your own groups for this purpose. The figure below shows that I’ve created a group called AppServers and I’ve added the APP1 computer account to that group.
Figure 1
Open the UAG management console on the UAG DirectAccess server after you create the group. In the UAG Management console, click the Configure or Edit button in the Application Servers section (it will say Edit if you’ve already configured DirectAccess, and it will say Configure if this is the first time you’ve configured DirectAccess).
Figure 2
On the Application Server Configuration page you’re given the option to Require end-to-edge authentication and encryption and Require end-to-end authentication and encryption to specified application servers. These “options” aren’t really options, as you must always have end-to-edge encryption and authentication. Remember, end-to-edge security represents the security delivered by the IPsec tunnels between the DirectAccess client and UAG DirectAccess server.
However, the Require end-to-end authentication and encryption to specified application servers option is an option. If you want to require end-to-end security between the DirectAccess client and the server on the intranet, you will need to select this option and then click Add to add the groups that contain the computer accounts of the servers that you want end-to-end security enforced.
Figure 3
Notice in Figure 3 that there is a link for Edit IPsec cryptography settings. You might run into some issues using that link if you’re using UAG RTM, so if you want to change the Quick Mode settings, it’s best to do it in the Group Policy Object that’s created for the Application Server connections. However, it should work fine with UAG Update 1 and above. Make sure to confirm. If you don’t use Update 1 (which shouldn’t be the case since you should always install it, but we didn’t have Update 1 available when the Test Lab Guide was written.) You can see where this is done in Figure 4. I won’t go into the details on how to do this, but if you are already comfortable with IPsec configuration, it’s relatively easy. However, each time you redeploy the UAG Group Policy settings when using the UAG DirectAccess wizard, you should confirm that your custom changes have been retained; you may need to reconfigure them.
Note that the name for the Application Servers Group Policy Object is:
Figure 4
(UAG DirectAccess: AppServer{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}
Figure 5
After you make the changes in the UAG DirectAccess wizard in the UAG management console, you need to deploy the settings. After the GPO settings are deployed, make sure you refresh Group Policy on the Application Servers and the DirectAccess clients so that they receive the new Connection Security Rules. You can use gpupdate /force to do this in the Test Lab.
After Group Policy is refreshed, you can go to a DirectAccess client and open the Windows Firewall with Advanced Security console and check the Connection Security Rules. You will see a new Connection Security Rule named UAG DirectAccess Client – Clients E2E Authentication.
Figure 6
If you double click on the rule you’ll see on the General tab the description that explains that the policy is to enable secure corporate resources over IPsec.
Figure 7
On the Computers tab, you see in the Endpoint 2 section that the rule is applied when the DirectAccess client connects to the IPv6 address of the secure server on the intranet. This is why end-to-end security only works when the DirectAccess client connects to IPv6 capable hosts – the Connection Security Rule needs to use the IPv6 address of the secure server on the intranet. In the example in Figure 8, that address is assigned to APP1.
Figure 8
When you click on the Protocols and Ports tab, you can see that the rule applies to all protocols, as seen in Figure 9.
Figure 9
Click on the Authentication tab. Note that the authentication mode is to Require inbound and outbound authentication. Click the Customize button.
Figure 10
This brings up the Customize Advanced Authentication Methods dialog box (Figure 11). Remember, you can’t change anything here because these settings are managed via Group Policy, but you can see what the Group Policy controlled settings are. Both Computer certificate and user Kerberos authentication is required to establish the secure IPsec connection between the DirectAccess client and secure server on the intranet.
Figure 11
Click on the Advanced tab (Figure 12) and you’ll see that this rule is active only for the Private and Public profiles. This is important because you want these settings to apply only when the DirectAccess client is acting as a DirectAccess client; that is to say, when the DirectAccess client is off the intranet. When the DirectAccess client is on the intranet, you don’t want this Connection Security Rule to activate. The reason for this is that you might have other Connection Security Rules and IPsec policies that you want your intranet clients to use, perhaps as part of your Server and Domain Isolation configuration.
Figure 12
After you establish a connection to the secure server (I did a net view \\APP1 in this example), click the Monitoring\Security Associations\Main Mode node and expand the Remote Address column. There you will see a Main Mode SA with APP1 to its IPv6 ISATAP address, using both Computer Certificate and User (Kerberos V5) authentication, as seen in Figure 13.
Figure 13
Double click on the Main Mode SA to the secure server on the intranet and you can be more details. As you can see in Figure 14, the name of the user is listed, as well as the encryption and integration methods used by the connection.
Figure 14
Similarly, if you click on the Quick Mode node in the left pane of the console, you’ll see the Quick Mode SA established with APP1 on the intranet. Here you can see the local and remote address, and the integrity and encryption methods used for the connection, as seen in figure 15.
Figure 15
Now that we’ve seen what things look like on the DirectAccess client, let’s move our attention to the secure server on the intranet. If you’re following along with the Test Lab Guide, open the Windows Firewall with Advanced Security console on APP1 and click on the Connection Security Rules node in the left pane of the console. Here you’ll see that there are two new rules: UAG DirectAccess AppServer – Clients E2E Authentication and UAG DirectAccess AppServer – HTTPS Clients E2E Authentication, as you can see in figure 16.
Figure 16
Why are there two Connection Security Rules? To get a clue, double click on the UAG DirectAccess AppServer – Clients E2E Authentication rule and click on the Computers tab (figure 17). Here you can see that Endpoint 1 has two IP address ranges. One of the ranges reflects the addresses that are assigned to Teredo DirectAccess clients and the other is for 6to4 DirectAccess clients. Endpoint 2 represents the secure server on the intranet, so no IP address needs to be assigned there.
Figure 17
Click on the Advanced tab (figure 18). Notice that the Connection Security Rule is assigned to the Domain profile. The reason for this is that the secure server on the intranet isn’t going to be moving anywhere, so there’s no reason to have the rule apply to Private or Public Profiles.
Figure 18
Now let’s take a look at the other Connection Security Rule, UAG DirectAccess AppServer – HTTPS Clients E2E Authentication. Double click on that rule and click on the Computers tab. Notice the address range for Endpoint 1. If you’re been working with DirectAccess for a while, you might recognize this IPv6 address range. If not, this range represents the DirectAccess clients that are using IP-HTTPS to connect to the UAG DirectAccess server.
Figure 19
In the article we took a short look at some of what you’ll see when configuring end-to-end security between the DirectAccess client on the Internet and a server on the intranet. In contrast to IPsec tunnel mode that is used to connect the DirectAccess client to the UAG DirectAccess server, the DirectAccess client uses IPsec transport mode to connect to the secure server on the intranet. When you configure end-to-end security, the UAG DirectAccess wizard will create new Connection Security Rule that are applied to the DirectAccess clients and secure servers on the intranet. You can use the Windows Firewall with Advanced Security console to see the Connection Security Rules and the status of the IPsec connections.
This article is just an short introduction to end-to-end security. I plan to put together a Test Lab Guide on configuring UAG DirectAccess with end-to-end security, so keep your eyes open for it! See you soon –Tom.
Tom Shinder tomsh@microsoft.com Microsoft DAIP 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
“Why does SharePoint ask for credentials when I connect over DirectAccess?”
There is a very long thread on the TechNet forums regarding an unusual authentication issue when DirectAccess clients try to connect to SharePoint sites. There were a lot of posts and a lot of effort was made to determine the nature of the problem. The good news I have for you today is that we’ve solved the problem and have published a fix!
The problem was due to the fact that the automatic logon level for Windows HTTP Services (WinHTTP) is Medium. When the automatic logon level is set to Medium, it prevents the user credentials from being automatically sent to the web server. The end result is that the address is considered an Internet server when you try to access the WebDAV resource like SharePoint which leads to you being asked for credentials.
Here’s the fix for the problem:
http://support.microsoft.com/kb/2288297
I’ve been pretty quiet for most of this month (in fact, this is the first post on the Edge Man blog for March). I was in Redmond for the world wide MVP conference for a week and then spent a week to meet with members of my team on how we’ll approach documentation for the next version of Windows. It was a great visit but pretty tiring. I spent all of last week trying to get caught up and also preparing for a presentation of our content plan. I hope they like it, and even more important, I hope that YOU all like what we have planned for you!
One of the things that we hope to provide you in the future is an increasingly robust collection of Test Lab Guides. If you don’t know about Test Lab Guides and what they’re all about, then check out my post at
http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
We also have a great Test Lab Guide blog where you can get the latest information about Test Lab Guides and ask questions about Test Lab Guides. The Test Lab Guide blog is over at
http://blogs.technet.com/b/tlgs/
Finally, if you want to find a comprehensive list of Test Lab Guides, head on over to the TechNet wiki
http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx?wa=wsignin1.0
Now that you know all about Test Lab Guides, I want to take this opportunity to tell you about a new Test Lab Guide!
The new Test Lab Guide walks you through the setup and initial configuration of System Center Service Manager and you can find this Test Lab Guide over at:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=b276879e-380f-4b40-809e-1574f4059277
Its exciting to see the System Center folks releasing Test Lab Guides! As you know, System Center products are broad and deep, and its hard to figure out how things work from end-to-end without getting your hands-on in a Test Lab . Test Lab Guides are the ideal way to get that hands on experience and I’m looking forward to more great TLGs coming from our friends in System Center.
Thanks!
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Hey folks – since the TLGs are typically put up only in the download center, it makes discoverability of some of the cool content inside of them hard when it comes to search engines. Therefore, I’m going to post the full text of the TLGs on the Edge Man blog. However, I recommend that you download the Word .doc version of the TLGs when you actually put together your Test Lab using the Test Lab Guides.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Remote Management check out:
http://go.microsoft.com/fwlink/?LinkId=205210
==================================================
Introduction
Forefront Unified Access Gateway (UAG SP1 RC) provides users with the experience of being seamlessly connected to their intranet any time they have Internet access. When DirectAccess is enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without the need for users to connect to a VPN. DirectAccess enables increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside of the office. Forefront UAG SP1 RC DirectAccess extends the benefits of Windows DirectAccess across your infrastructure by enhancing availability and scalability, as well as simplifying deployments and ongoing management. For more information, see Overview of Forefront UAG DirectAccess.
This Test Lab Guide provides step-by-step instructions for configuring Forefront UAG SP1 RC DirectAccess Remote Management in a test lab so that you can see how it works. You will set up and deploy Forefront UAG SP1 RC DirectAccess using 5 server computers, two client computers, Windows Server 2008 R2 Enterprise Edition, Windows Server 2003 Enterprise Edition SP2, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates Forefront UAG SP1 RC DirectAccess in different Internet connection scenarios.
Important:
These instructions are designed for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed to work only on a separate test lab network. For more information on planning and deploying DirectAccess with Forefront UAG SP1 RC, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
This Test Lab Guides builds on the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. You will need to complete all the steps in that guide before you can complete the steps in this Test Lab Guide.
In this test lab scenario, Forefront UAG SP1 RC DirectAccess is deployed with:
The test lab consists of three subnets that simulate the following:
Computers on each subnet connect using either a physical or virtual hub or switch, as shown in the following figure.
The following components are required for configuring Forefront UAG SP1 RC DirectAccess in the test lab:
The following steps describe how to configure the server and client computers, in a test lab. Following these configurations you can verify DirectAccess connectivity from the Internet and Homenet subnets. In addition, you will see how you can manage DirectAccess clients from management computers on the intranet. This Test Lab Guide also highlights a new feature included in UAG SP1 RC, which allows you to limit DirectAccess client connectivity to the intranet tunnel only, which enables continuous management of DirectAccess clients without allowing users to access resources on the intranet.
Note:
You must be logged on as a member of the Domain Admins group or as a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.
You will perform the following steps to demonstrate UAG SP1 RC DirectAccess remote management in this Test Lab Guide:
· Step 1: Complete the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess – This Test Lab Guide builds on the configuration created after completing the steps in Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
· Step 2: Configure Remote Management – In this step you will create the DirectAccess client OU, create and configure a DirectAccess client GPO and refresh the remote access client configuration and enabling remote desktop connectivity to DirectAccess clients.
· Step 3: Test Remote Management of DirectAccess Clients – After the new firewall settings are deployed to the DirectAccess client, management servers on the corporate network can initiate connections to the DirectAccess client. In this step you validate the settings and establish connections from DC1 to CLIENT1, when CLIENT1 is acting as a DirectAccess client behind NAT1.
· Step 4: Limit DirectAccess Client to Only the Management Tunnel. In this step you will configure UAG1 to limit DirectAccess client connectivity to only the infrastructure tunnel.
· Step 5: Snapshot the Configuration. After completing the Test Lab, take a snapshot of the working UAG SP1 RC DirectAccess NLB array so that you can return to it later to test additional scenarios.
The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. After completing the steps in that Test Lab Guide you will have the core infrastructure required to complete this Test Lab Guide on how to configure UAG SP1 RC DirectAccess remote management. If you have already completed the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide and saved the configuration in either a virtual machine snapshot or disk image for a physical deployment, you can restore that configuration and begin with the next step.
DirectAccess uses two IPsec tunnels between DirectAccess client and server to enable communications to the corporate network. The first IPsec tunnel is the “infrastructure” tunnel. This tunnel is established after the DirectAccess client computer starts, but before the user logs on. Authentication is required for this tunnel, and both a computer certificate and the computer account in Active Directory are used to authenticate the first IPsec tunnel connection. The second tunnel (the intranet tunnel) is established after the user logs on and allows the user to access network resources. Authentication for this tunnel uses computer certificate and user (Kerberos) authentication in Active Directory.
The infrastructure tunnel provides bidirectional access to and from servers included in the management servers collection, as defined in the DirectAccess configuration wizard. These servers can connect to DirectAccess clients over the infrastructure tunnel, so that connectivity is enabled whenever the DirectAccess client computer is turned on, regardless of whether the user is logged on. The infrastructure tunnel enables remote management scenarios where administrators can apply patches, make configuration changes, and employ their full suite of configuration and management tools not only to computers on the corporate network, but to any DirectAccess client on the Internet.
You will perform the following procedures to enable several remote management scenarios:
A. Create the DirectAccess Client Organizational Unit and Place CLIENT1 in the New OU. New firewall rules are required to enable some aspects of remote management of DirectAccess clients. Firewall rules can be configured on each client individually, but it is more efficient to use Group Policy to distribute the new firewall rules to all DirectAccess clients. Changes could be made to the DirectAccess Client GPO created by the UAG SP1 RC DirectAccess wizard, but these settings are overwritten each time the wizard is run. Therefore, you will create new GPO to support these custom settings. The new GPO is then linked to an OU that is populated with the DirectAccess client computer accounts.
B. Create and Configure the DirectAccess GPO and Link it to the DirectAccess Client OU. The DirectAccess GPO is linked to the DirectAccess client OU. In this step you create and populate the DirectAccess client OU.
C. Refresh the DirectAccess Client Configuration and Enable Remote Desktop Connections to CLIENT1. The DirectAccess clients need to refresh this Group Policy configuration to receive the new GPO settings. In this step the DirectAccess client refreshes it Group Policy configuration to receive the new firewall settings.
Remote management scenarios for DirectAccess clients can happen in two ways. In the first scenario, the DirectAccess client contains one or more management agents that initiate connections to management servers on the corporate network over either the infrastructure or intranet tunnel. If the user is not logged on, the management agents can initiate connections to management servers over the infrastructure tunnel. If the user is logged on, either the infrastructure or intranet tunnel can be used by the DirectAccess client to connect to the intranet. No special firewall rules are required for the DirectAccess client to initiate connections to management servers.
In the second scenario, management servers initiate connections to the DirectAccess client. Special Windows Firewall with Advanced Security firewall rules are required to enable management servers to initiate connections to Active Directory clients when the DirectAccess client is located behind a NAT device. These firewall rules must be configured for each desired protocol used to initiate the connection to the DirectAccess client, and then each of these rules must enable Edge Traversal.
The special firewall rules can be configured on each DirectAccess client individually. However, this manual approach does not scale. A better solution is to use Active Directory Group Policy to configure and distribute the new firewall rules for the desired protocols with Edge Traversal enabled.
While it is possible to configure these rules using the GPO created by the UAG SP1 RC DirectAccess wizard, these GPO settings are overwritten each time the wizard is run and the new GPO settings deployed. A viable alternative is to create a new GPO and a new Organizational Unit for the DirectAccess clients. The new DirectAccess client GPO can be linked to the new OU to apply the firewall rules required for management servers to initiate connections to the DirectAccess clients.
Note: DirectAccess clients using the 6to4 IPv6 transition technology to connect to the DirectAccess server do not require special firewall rules with Edge Traversal. However, since you cannot predict when any specific DirectAccess client will use any specific IPv6 transition technology at any specific point in time, you should always enable Edge Traversal on your firewall rules.
To apply the GPO settings to the DirectAccess clients, we create an Organizational Unit that will contain the DirectAccess clients. The DirectAccess GPO is linked to the new OU. The first step is to create the DirectAccess OU and place the CLIENT1 into this OU.
The following steps are carried out on DC1.
DirectAccess clients that connect to the DirectAccess server using Teredo or IP-HTTPS need special Firewall Rules to support “manage out” connections. These firewall rules are created for each protocol needed to connect from the intranet to the DirectAccess client. By default, there are no Firewall Rules that allow outbound management from management servers on the intranet, so you must create rules to allow the required protocols. The best way to deploy these Firewall Rules is by configuring them in Group Policy so that the settings are automatically deployed. In this example we will create rules that allow management computers on the corpnet to connect to DirectAccess clients on the Internet using Ping, File Services and Remote Desktop Protocol. Perform the following steps on DC1.
CLIENT1 needs to receive the firewall rules configured in Group Policy. That can be done by initiating a Group Policy refresh while CLIENT1 is running as a DirectAccess client on the Internet. In addition, CLIENT1 needs to be configured to allow Remote Desktop connections before it can accept RDC connections from a management server on the corpnet. Perform the following steps on CLIENT1.
The DirectAccess client is now ready for remote management using the protocols configured in the Firewall Rules that allow for Edge Traversal. Perform the following procedures on DC1. The procedures are performed on DC1 because DC1 is the only computer that is on the management servers list and therefore the only one that can connect to CLIENT1 over the infrastructure tunnel. In addition, CLIENT1 will be restarted, but you will not log on, so that DC1 will be forced to use the infrastructure tunnel to connect to CLIENT1. The intranet tunnel is only available after the user logs on to the DirectAccess client computer.
While seamless access to the intranet for DirectAccess clients is a compelling use case for DirectAccess users, many IT organizations find the remote management capabilities even more useful. There may be some organizations that prefer that only the infrastructure tunnel be available so that DirectAccess client are always managed, but that users cannot access resources on the intranet. UAG SP1 RC includes a new feature that allows you to configure DirectAccess clients so that they only have access to the intranet tunnel.
In this step we will demonstrate how to configure DirectAccess clients so that they have access only to the intranet tunnel so that they can be always managed:
1. *At UAG1, click Start and then click All Programs. Click Microsoft Forefront UAG and then click Forefront UAG Management. In the User Account Control dialog box, click Yes.
2. In the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess in the left pane of the console.
3. In the right pane of the console, in the Step 1 Clients and GPOs section, click Edit.
4. This starts the Clients and GPOs Configuration wizard. On the Deployment Model page, select the Enable remote management of DirectAccess client only option. Confirm that there is a checkmark in the Allow only services running under the client computer account to access infrastructure servers used for remote management checkbox. This option allows system services running in the context of the local computer account to connect to infrastructure servers through the infrastructure tunnel, but does not allow processes running in the context of the logged on user account to reach infrastructure servers. In addition, because the intranet tunnel cannot be established, the user cannot reach any other server on the intranet. Click Next.
5. On the Client Domains page, click Next.
6. On the Policy Management page, click Next.
7. On the Client Groups page, click Finish.
8. In the right pane of the Microsoft Forefront Unified Access Gateway Management console, click the Apply Policy button.
9. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. Click OK in the DirectAccess Policy Configuration dialog box after you see it report Script run completed with no errors or warning.
10. On the Forefront UAG DirectAccess Configuration Review page, click Close.
11. Open and elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Close the command prompt window when the command completes.
12. *Go to CLIENT1. Log on as CORP\User1. Open an elevated command prompt. In the command prompt window, enter gpupdate /force and press ENTER. Notice that the gpupdate fails, as this command is run under the user context.
13. In the command prompt window, enter net view \\dc1 and press ENTER. You will see that you get a System Error 53 occurred. The network path was not found. Again, the connection attempt fails because the command is sent in the context of the current user.
14. In the command prompt window, enter ping dc1 and press ENTER. You will see four responses from DC1’s ISATAP assigned IPv6 address. This indicates that DNS queries are working correctly over the infrastructure tunnel. DNS queries are sent by the DNS client service in the context of the local computer account, so CLIENT1 was able to resolve the name of DC1. The ping request was send in the context of the local user account. This request was successful because ICMPv6 communications are not sent over the IPsec tunnel, therefore there is no authentication failure.
15. *Return to DC1. Open and elevated command prompt. In the command prompt window enter net view \\client1 and press ENTER. Notice that you can still access CLIENT1 because DC1 connects to CLIENT1 through the infrastructure tunnel.
16. On DC1, open Event Viewer from the Administrative Tools menu. Review the entries related to CLIENT1 starting up and receiving Group Policy settings and machine authentication. This further demonstrates that CLIENT1 was able to communicate with DC1 during the startup process because of the access provided over the infrastructure tunnel.
This completes the UAG SP1 UAG SP1 RC DirectAccess remote management test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess remote management configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
1. On all physical computers or virtual machines in the test lab, close all windows and then perform a graceful shutdown.
2. If your lab is based on virtual machines, save a snapshot of each virtual machine and name the snapshots UAG SP1RC DirectAccess Remote Management. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration
For procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.
For procedures required to build this Test Lab Guide, see Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG SP1 RC DirectAccess design guide and the Forefront UAG SP1 RC DirectAccess deployment guide.
For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.
For information on how to troubleshoot UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshoot UAG DirectAccess.
For a comprehensive list of UAG DirectAccess Test Lab Guides, see Test Lab Guides.
For more information about DirectAccess, see the DirectAccess Getting Started Web page and the DirectAccess TechNet Web page.
===================================
Tom Shinder tomsh@microsoft.com Knowledge Engineer, Microsoft DAIP 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
An interesting question came up a few weeks ago regarding DirectAccess and expiring computer accounts. I thought it was an topical question that brought up some issues worth exploring, so I’m sharing with you some thoughts on the problem here.
First a little background. UAG DirectAccess (and Windows DirectAccess) enables the DirectAccess client to connect to the intranet through the use of two tunnels:
The infrastructure tunnel enables the DirectAccess client to reach computers on the intranet that are part of an administrator defined “management servers” group. The DirectAccess client uses this tunnel to communicate with domain controllers, update servers and other servers that you’d like the DirectAccess client to be able to connect to before the user logs on.
The intranet tunnel is opened after the user logs onto the DirectAccess client computer. This tunnel enables access to the rest of the intranet.
Both the intranet and the infrastructure tunnels require two forms of authentication to succeed before the tunnels are established.
For the infrastructure tunnel, the DirectAccess client must be able to succeed at:
For the intranet tunnel, the DirectAccess client must be able to succeed at:
Note that in order to perform Kerberos authentication, you need to have connectivity to a domain controller. The domain controller should be reachable through the infrastructure tunnel that was established before the user attempts to log on.
With that understanding in place, you can see if that a computer account had expired for some reason, the infrastructure tunnel could not be created, since it depends on computer account (NTLMv2) authentication. And if you can’t get the first tunnel opened, you can’t get the second tunnel opened (the intranet tunnel), since the Kerberos authentication required for the second tunnel depends on the first tunnel coming up.
So what would happen if a computer account password expired? Nothing. The reason for this is that the computer itself is responsible for changing its password. If the computer is offline for six months and then brought online, nothing bad will happen. The computer will change its password when it starts up. This means that if for some reason a DirectAccess client computer is offline for more than 30 days (the default value for computer account password expiration) there won’t be any problems connecting to the intranet and establishing both of the IPsec tunnels.
For more information on how computers change their computer account passwords, see http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx
However, there is one scenario that might be problematic, and if you manage a DirectAccess deployment, you might want to take this into consideration. Some firms “clean up” their computer accounts on a periodic basis. During the clean-up, they might disable the stale computer accounts, or they might delete them. In this scenario, the DirectAccess client will not be able to establish the infrastructure tunnel and therefore will not be able to establish the intranet tunnel. If the computer account is disabled, it will need to be enabled. If it was deleted, the computer will need to leave the domain and rejoin the domain; this can be done over an SSTP connection.
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess with SSTP check out:
http://go.microsoft.com/fwlink/?LinkId=206283
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 intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.
Forefront Unified Access Gateway (UAG) SP1 RC extends the value of the Windows DirectAccess solution by adding features that meet the requirements of many enterprise deployments:
To learn more about UAG DirectAccess, see the following resources:
· Forefront UAG DirectAccess Design Guide
· Forefront UAG DirectAccess Deployment Guide
UAG SP1 RC supports hosting multiple roles on a single UAG server or UAG array. For example, you might want to host both the DirectAccess server and SSTP VPN server roles on the same server or array. Windows 7 clients that are configured DirectAccess clients will automatically use DirectAccess to connect to intranet resources. Windows 7 clients that are not domain members, or who are not configured as DirectAccess clients can use SSTP to connect to the intranet using a network level VPN connection. In addition, DirectAccess clients hosting applications that are not compatible with DirectAccess can connect to the SSTP VPN when they need to use the non-compatible application.
Note
Non-Windows 7 operating systems (such as Windows Vista, Windows XP) can use the UAG Network Connector to connect to the intranet using a network level SSL VPN connection. However, you cannot host the Network Connector application on the same server or array that is also hosting DirectAccess. To support network level VPN connectivity for non-Windows 7 clients, you will need to deploy a second UAG server or array.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with SSTP in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates a co-located Forefront UAG DirectAccess and SSTP VPN server role deployment. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
These instructions are designed for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network, and to show clearly the required functionality. This configuration is not designed to reflect best practices, nor does it reflect a required or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed to work only on a separate test lab network. For more information on planning and deploying DirectAccess with Forefront UAG, please see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide
In this test lab scenario, Forefront UAG DirectAccess SP1 RC is deployed with:
The following components are required for configuring Forefront UAG DirectAccess in the test lab:
This Test Lab Guide demonstrates a combined UAG SP1 RC DirectAccess and SSTP deployment.
Important
The following instructions are for configuring a test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network and to clearly show the desired functionality. It is important to remember that this configuration is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab network.
Attempting to adapt this test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess and SSTP, please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.
The following sections describe how to configure UAG1 as both a DirectAccess and SSTP VPN server. After UAG1 is configured, this guide provides steps for demonstrating the DirectAccess and SSTP VPN functionality for CLIENT1 when it is connected to the Homenet subnet.
You must be logged on as a member of the Domain Admins group or a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group. For all tasks described in this document you can use the CONTOSO\User1 account created when you went through the steps in the UAG DirectAccess Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
The following procedures are performed to enable and allow you to test the UAG SP1 RC DCA:
· Step 1: Complete the Demonstrate UAG SP1 RC DirectAccess Test Lab Guide – The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess.
· Step 2: Create the HTTPS Trunk. UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.
· Step 3: Configure the Remote Network Access Settings. The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.
· Step 4: Add the SSTP Remote Network Access Application to the Trunk. In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.
· Step 5: Activate the Configuration and View Activation in the Activation Monitor. You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.
· Step 6: Test DirectAccess and SSTP Connectivity. After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.
· Step 7: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with SSTP Test Lab so that you can return to it later to test additional scenarios.
You will notice that there are several steps that begin with an asterisk (*). The * indicates that the step requires that you move to a computer or virtual machine that is different from the computer or virtual machine you were at when you completed the previous step.
The first step is to complete all the steps in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess. After completing the steps in that Test Lab Guide you will have the core infrastructure required to complete this Test Lab Guide on how to configure the UAG DirectAccess DCA. If you have already completed the steps in that Test Lab Guide and saved a snapshot or disk image of the Test Lab, you can restore the snapshot or image and begin with the next step.
UAG uses the concept of “trunk” as the primary listener for incoming SSL connections to a UAG portal page. In this step you will create an SSL Trunk that can be used to create a portal page that includes the SSTP VPN application.
The SSTP application requires configuration of a number of settings before it can be deployed. In this step you will configure these settings.
In order for users to access the SSTP VPN application, that application must be added to a trunk. In this step you will add the SSTP application to the HTTPS trunk.
You need to activate the configuration after adding the SSTP VPN application to the trunk. In this step you will activate the configuration and view the activation process in the Activation Monitor.
After activation is complete, you are ready to test both DirectAccess and SSTP connectivity. In this step you will confirm DirectAccess connectivity and then start an SSTP VPN connection through the portal.
This completes the UAG SP1 RC DirectAccess with SSTP test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
For more information on UAG and SSTP, see Setting up Remote Network Access.
For procedures to configure UAG SP1 RC DirectAccess on which this document is based, see the Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess.
For a comprehensive list of Test Lab Guides, please see Test Lab Guides.
For a list of UAG DirectAccess related Test Lab Guides, please see UAG DirectAccess Test Lab Guide Portal Page
For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.
For information on troubleshooting UAG DirectAccess in a Test Lab, see Test Lab Guide: Troubleshooting UAG DirectAccess.
For a downloadable version of the Test Lab Guide – Demonstrate UAG SP1 RC DirectAccess Connectivity Assistant check out:
http://go.microsoft.com/fwlink/?LinkId=205738
The Microsoft DirectAccess Connectivity Assistant (DCA) supports a DirectAccess client computer that is running Windows 7 by clearly indicating the state of DirectAccess connectivity to corporate network resources. It provides easy access to troubleshooting information and makes it simple to create and send log files to support personnel.
Without the DCA, when a user’s Internet connection (for example, http://www.bing.com) appears to be available, but corporate network resources are not accessible, there is no way that the user can verify if the problem is caused by DirectAccess not working correctly. This can result in user frustration and increased Help Desk support calls. The DCA clearly indicates the operational status of DirectAccess by using an icon in the notification area and informational messages. This helps the user identify the problem area and helps direct troubleshooting efforts.
If DirectAccess is not working correctly, the DCA clearly indicates the status by changing the icon in the notification area and by sending informational messages that provide more detail about the failure. The DCA provides the user with easy access to an extranet URL. For example, this URL might point to a Web site that hosts support information for the organization’s user community. The user can easily send diagnostic log files to the DirectAccess support staff. The log files can contain the default information. The UAG SP1 RC DCA includes comprehensive advanced diagnostics built-in. The administrator can also include a script in the DCA configuration that creates additional diagnostic information that is included in the log files sent to the support team.
This guide provides step-by-step instructions for configuring UAG DirectAccess SP1 RC with the DirectAccess Connectivity Assistant in a test lab so that you can see how it works. You will set up and deploy UAG DirectAccess SP1 RC using five server computers, two client computers, Windows Server 2008 R2 Enterprise edition, and Windows 7 Ultimate Edition. The Test Lab simulates intranet, Internet, and a home networks, and demonstrates the Forefront UAG DirectAccess Connectivity Assistant. The starting point for this paper is the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess .
This Test Lab Guide demonstrates the UAG DirectAccess SP1 RC DirectAccess Connectivity Assistant.
For more information about the different modes of NAP, see Stages of a NAP Deployment.
Attempting to adapt this test lab configuration to a pilot or production deployment can result in configuration or functionality issues. To ensure proper configuration and operation of UAG DirectAccess , please refer to the Forefront UAG DirectAccess Deployment Guide for the steps to configure the UAG DirectAccess server and supporting infrastructure servers.
The following sections describe how to configure UAG1, DC1 and CLIENT1 for UAG SP1 RC and the DCA. After UAG1, DC1 and CLIENT1 are configured, this guide provides steps for demonstrating the DCA functionality for CLIENT1 when it is connected to the Homenet subnet.
· Step 2: Configure INET1 with a Help.txt file. The DCA can provide DirectAccess users information about a web site they can go to in order to get help with DirectAccess related problems. In this step you will configure a web page that CLIENT1 can reach to get that help.
· Step 3: Install and Configure the Web Server Role on DC1. The DCA uses a number of connectivity verifiers to determine intranet connectivity over the DirectAccess IPsec tunnels. In this step you will configure DC1 as a web server so that the DCA can use HTTPS to DC1 for a connectivity verifier.
· Step 4: Run the UAG DirectAccess DCA Configuration Wizard on UAG1. UAG SP1 RC includes a new integrated DCA wizard that automatically configures and deploys GPO settings that enable the DCA. In this step you will run the UAG SP1 RC DCA wizard.
· Step 5: Update Group Policy on CLIENT1 and Test DCA Functionality. The new DCA settings are deploy via the DirectAccess clients GPO. In this step you will update Group Policy on CLIENT1 and then test some of the DCA features.
· Step 6: Snapshot the configuration. After completing the Test Lab, take a snapshot of the working UAG DirectAccess with NAP Test Lab so that you can return to it later to test additional scenarios.
The DCA can expose to DirectAccess users a link to a location where they can find help. This location is configured in the UAG DirectAccess DCA wizard. In this step you will configure a Help.txt file that CLIENT1 will connect to when acting as a DirectAccess client.
The UAG DCA uses connectivity verifiers to determine DirectAccess connectivity to the intranet over the DirectAccess tunnels. Connectivity verifiers can use HTTP, HTTPS and SMB to assess the current connectivity status to the intranet over the DirectAccess IPsec tunnels. In this step you install the web server role on DC1 and then bind a certificate to the web site so that the DCA can establish an SSL session with DC1 to determine intranet connectivity.
UAG SP1 RC includes a new wizard that enables you to configure the DCA so that you don’t have to manually configure Group Policy to support the DCA. In this step you will run the DCA wizard so that it will automatically provision Group Policy to configure the DCA on DirectAccess clients.
In this step you will update Group Policy on CLIENT1 so that it receives the new DCA related settings. Then you will install the DCA client software and finally test DCA functionality when CLIENT1 is located on the Homenet subnet.
Update Group Policy on CLIENT1:
Install the DCA software on CLIENT1:
Test DCA Functionality on CLIENT1:
It is important to note that the DCA icon may show a red “x” even when there is connectivity to the intranet. The red “x” appears when any of the connectivity verifiers is unavailable to the DirectAccess client. It is recommended that you specify a diverse set of resources for your connectivity verifiers. This diversity helps ensure that a failure to access a resource is an unambiguous indication of a problem with DirectAccess rather than a problem with another component.
For example, if all of the specified resources are behind a network address translating application layer gateway (NAT64), the failure of DCA to access the test resources might indicate a failure of the NAT64 rather than a failure of DirectAccess. Instead, identify one resource behind the NAT64, another behind an ISATAP gateway, and so on. Also note that you must not use the Network Location Server as a connectivity verifier, since the name of the Network Location Server cannot be resolved by the DirectAccess client.
This completes the UAG SP1 RC DirectAccess Connectivity Assistant test lab. To save this configuration so that you can quickly return to a working UAG SP1 RC DirectAccess Connectivity Assistant configuration from which you can test other DirectAccess modular TLGs, TLG extensions, or for your own experimentation and learning, do the following:
2. If your lab is based on virtual machines, save a snapshot of each virtual machine and name the snapshots TLG UAG DirectAccess SP1RC DCA. If your lab uses physical computers, create disk images to save the DirectAccess test lab configuration.
For a comprehensive list of UAG DirectAccess Test Lab Guides, please see Test Lab Guides.
A couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.
====================================
“Can you clarify a couple points related to Certificate Authorities and CRLs? I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide? The CA created on the domain server is completely separate from this commercial certificate, right?…”
The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).
The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.
Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?
In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.
You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.
The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.
========================================================
“And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment. Is this only because of performance reasons or because of something else? And is this CRL not related to the IP-HTTPS listener? So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections. Is that right?…”
There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.
You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:
It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Forefront 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
Shannon Fritz, and up and comer in the world of UAG DirectAccess found a very interesting issue with the UAG Management Console and loading of the DirectAccess interface. It turns out that if the UAG server has a NetBIOS name that is longer than the allowed 15 characters, the DirectAccess configuration interface won’t open.
Here’s a screenshot from the TechNet forums of what Shannon saw:
The Product Group is now aware of this issue, and we’ll make plans to update documentation to warn against using NetBIOS names longer than 15 characters.
You should also check out Shannon’s blog over at:
http://blog.concurrency.com/infrastructure/uag-cannot-load-the-directaccess-view-0
for more information on what he found.
Most of you probably know this, but before I joined Microsoft I spent most of my time with ISA Server and Threat Management Gateway (TMG). A big part of my life was ISAserver.org (www.isaserver.org). My affiliation with ISAserver.org started in mid-2000 and continued uninterrupted until I joined Microsoft in December 2009. However, even after joining Microsoft, I’ve continued to post to the web forums on ISAserver.org because the community for ISA and TMG and UAG is so active there.
The web forums were my favorite experience at ISAserver.org. From those forums I got to know many people, and became friends with a lot of them, over the years. ISAserver.org brought together people from all over world to have professional and interesting discussions about our favorite firewall: ISA Server (now TMG). I can honestly say that my life would have been a poorer experience if I hadn’t participated and met so many great people because of my involvement with the ISAserver.org web forums.
So yesterday was a big day for me – I hit my 50,000th post on the web forums!
It took 10 years to do it, which means I averaged something like 5,000 posts per year. Of course, the number of posts per day was significantly higher in the days of ISA 2000 and ISA 2004 – ISA 2000 was a complete remake of Proxy Server 2.0 and somewhat of a challenge to understand and then when ISA 2004 was released, it represented a major remake of the user interface and required a lot of new learning. It was with the introduction of ISA 2004 that ISA became a true enterprise ready network firewall.
Because something like this only happens once, I decided to do a short movie of the event. If you’d like to watch the momentous occasion, then check out the video below.
While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.
==============================
Question/issue 1: I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG. They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.
I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected. I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.
I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).
My concept is this:
What I’d ultimately really love is a "test lab" document similar to the one already out there from Microsoft but designed to interface with the real internet instead of a fake internet. The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.
ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.
Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.
We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.
You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.
It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.
It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).
Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.
Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:
With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.
-----------------------------------------
Question 2: What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP? Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?
ANSWER:
ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.
In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.
Question 3: What are the security implications with opening up inbound IPv6 traffic into your network? Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place? Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?
IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.
While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.
I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
Ben Ari posted an answer to the Forwarding on the 6to4 Interface cannot be enabled error that you might see when you try to activate the DirectAccess configuration on the UAG DirectAccess server.
When you activate the configuration, it will look something like this:
Check Ben’s blog post at http://blogs.technet.com/b/ben/archive/2011/01/27/forwarding-on-the-6to4-network-interface-cannot-be-enabled.aspx for the reason and a fix.
Thanks Ben!
Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management/ICG Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Shannon Fritz, who’s well known on the UAG DirectAccess forums at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads for providing excellent community answers and insight, has put together a very nice UAG DirectAccess Configuration Guide. In Shannon’s configuration guide, you’ll find the following sections:
Check out all this and more over on Shannon’s blog at:
http://blog.concurrency.com/infrastructure/uag-directaccess-configuration-guide/
Hey folks,
You might have noticed that the old Edge Man hasn’t posted for almost a year. The Edge Man blog began as part of my work with UAG DirectAccess. I think we did a lot of great work here and provided some keen value for all of you who were working with UAG DirectAccess and even for those who were using the Windows DirectAccess. For you DirectAccess fans, I can assure you that DirectAccess is alive and well and I think you’ll find some welcome improvements as we move forward to the next version of DirectAccess. If you want to know more about that, then check the TechNet library.
While those were good times, its good to expand one’s horizons and explore new technologies and ways of thinking. I’ve since moved on from the UAG DirectAccess team and now work on the Server and Cloud Information Experience Solutions Group (that’s a mouthful!) Our primary focus is private cloud and you can find the body of our work in the Private Cloud Solutions Hub on TechNet.
My perspective on private cloud is that it provides you an opportunity to start over. I don’t see many people running data centers today who feel that their current datacenter is what they would have built on purpose. There are a number of reasons for this, but due to a confluence of things under their control and not under their control, their datacenters aren’t the well architected, well-designed, smooth running machines that they’d like them to be.
This is where private cloud represents a unique opportunity to start over. The private cloud provides you the chance to start over, to rebuild your datacenter into what you want it to be. And while some say (including myself) that the “cloud” presents a new paradigm for delivering software and services, the fact is that private cloud does all the things our current datacenters do – but does it in a way that enables them to be cheaper (sometimes), faster, more reliable, and better at delivering services to our customers.
So there you have it. The Edge Man has become the Private Cloud Architecture man. Does that mean I’m going to always have my head in the clouds and stick with conceptual stuff? Not likely. I’m doing a lot of work now on the technologies included in the Windows 8 operating system that enable the cloud. I’ll take a lot about those technologies in the future – but if you want an early glimpse of what I’ve been working on, check the TechNet library HERE.
As we move forward, I’ll run fun things like contests, games, and other things that will put some lightening into the cloud! Looking forward to you all joining my on this trek. It’s going to be a wild ride!
Tom Tom Shinder tomsh@microsoft.com Principal Knowledge Engineer, SCD iX Solutions Group Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Go Social with Private Cloud Architecture! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki
It’s done! The last in the set of UAG DirectAccess Test Lab Guides (at least for now, the effort is a continuous one).
If you haven’t heard about our Test Lab Guide efforts, check out:
In the troubleshooting UAG and NAP Test Lab Guide we go through a number of DirectAccess and NAP scenarios where we break something in the configuration and then use a number of DirectAccess and NAP troubleshooting tools to see what their output looks like when things get broken. Its a great way to get familiar with these tools and develop skills on how to troubleshoot problems with NAP in a UAG DirectAccess environment.
You can download the Troubleshooting UAG DirectAccess with NAP Test Lab Guide over at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e4037e34-09e7-41ab-a6d9-029394eb2d3d&displayLang=en
We also have a Troubleshooting UAG DirectAccess Test Lab guide which walks you through a number of scenarios where you break various components of UAG DirectAccess and then use a number of tools to solve the problem. It’s a fantastic way to learn some of the inner workings of DirectAccess and enables you to get that critical hands-on experience you need to troubleshoot UAG DirectAccess problems. You will learn something new about DirectAccess after going through this Test Lab Guide!
You can download the Troubleshooting UAG DirectAccess Test Lab Guide at:
Check out these Test Lab Guide and let me know what you think. We have other Test Lab Guides and we keep a clearinghouse of the available Test Lab Guides on the TechNet wiki. To see a list of currently available Test Lab Guides, head on over to:
http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
If you have an idea for a new Test Lab Guide for us to put together, then let me know! Send a note to tomsh@microsoft.com and put in the title New Test Lab Guide Suggestion. Or, if you think you can do a better job, write your own Test Lab Guide extension on the wiki.
Also, if you have any questions about the UAG DirectAccess Test Lab Guides, please feel free to post questions on the UAG DirectAccess forum over at:
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/threads
You’ve deployed DirectAccess on your network as a pilot project for your IT group over the holidays and everything is working great. When the users are behind a wide open NAT device, they use Teredo to connect to the UAG DirectAccess server. When they’re behind a port-restricted firewall or web proxy only, then they fall back to IP-HTTPS. Of course, you’d prefer that they use Teredo because it’s better performance. But IP-HTTPS connectivity is better than no connectivity at all.
Then it happens – the unthinkable!
Performance seems to slow down. You do an ipconfig and find that the Teredo interface isn’t starting up and only IP-HTTPS is being used. You move the client around, first behind a wide open NAT device and nothing changes. Then you disable the 6to4 interface and connect the client directly to the Internet. Still, only the IP-HTTPS interface comes up.
What’s up with that?
Here are some hints:
First, check out http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
Next, check out the graphic below:
Finally, check Ben Lee’s blog where he puts all the pieces together to come up with a solution over at http://www.bibble-it.com/2010/12/19/uag-directaccess-only-connects-via-ip-https
I shouldn’t have to say it – but you should always enable Microsoft Update on your UAG DirectAccess servers and arrays. In the third step of the UAG Getting Started Wizard you are given the opportunity to enable Microsoft Update (and also join the Microsoft Customer Experience Improvement Program, something I highly recommend). After you complete the step and activate the configuration, you would expect that the UAG server or array is going to update itself.
The problem is that sometimes (all the time?) Microsoft Updates fail. How to fix this?
One solution is found on the UAG TechNet forum. All you need to do is open an elevated command prompt and enter:
netsh winhttp set proxy localhost:8080
and press ENTER and BAM! Microsoft updates start working.
The most likely reason for this is that the UAG server needs to be configured as a web proxy client of the TMG server running on the same machine. When you run the netsh command, the proxy configuration is set to send web requests to the web listener on the local host network (the local host network is defined as all IP addresses assigned to the TMG firewall – which is the same as all the IP addresses assigned to the UAG DirectAccess server).
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
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
There’s a continuing debate in the IT Pro community whether or not you can host quality content on a wiki. If you don’t know what a wiki is, it’s a platform where anyone can post content and then after the content is posted, anyone can edit it.
Seems like a good idea, since IT Pros can share their collective experience and enhance the content – essentially creating a global “brain trust” that enables the possibility of creating the most comprehensive and most accurate content possible.
Of course, there are other perspectives on the intrinsic value of a wiki that let’s everyone edit documents. The following video embodies this sentiment.
Well, regardless of which end of the wiki debate you might find yourself, one thing is clear – there is a ton of great information on the TechNet wiki now, and the amount and the quality of the content continues to grow.
Proof of this comes from the recent posting of the Forefront Threat Management Gateway (TMG) 2010 Troubleshooting Survival Guide. Yuri Diogenes worked day and night, night and day, for weeks to put together this vital resource that is sure to benefit all TMG firewall administrators. You can find the TMG Troubleshooting Survival Guide over at:
http://social.technet.microsoft.com/wiki/contents/articles/forefront-threat-management-gateway-tmg-2010-troubleshooting-survival-guide.aspx
And remember – it’s on the wiki! That means you can add information, correct incorrect information, or even insert comments into the document. Share what you’ve learned about troubleshooting the TMG firewall. We want to you participate because It takes a village to troubleshoot the TMG firewall
When a DirectAccess client computer is on the Internet, it connects to the corporate network using DirectAccess. All communications between the DirectAccess client and DirectAccess server are done over IPv6 (encapsulated by an IPv4 tunnel to carry the IPv6 traffic over the IPv4 Internet). In fact, the client application assumes that the connection is IPv6 from end-to-end, even when the destination server on the intranet is an IPv4-only capable resource. UAG DirectAccess can enable IPv4 connectivity to an intranet resource by using its NAT64/DNS64 IPv6/IPv4 protocol translation feature, which allows the UAG DirectAccess server to map an IPv6 address associated with the IPv4 address of the intranet resource. This mapped IPv6 address is used by the DirectAccess client to connect to the IPv4 resource on the intranet. The UAG DirectAccess server will translate this to an IPv4 address and forward the connection to the desired IPv4-only resource on the intranet.
While NAT64/DNS64 solves the problem of IPv4-only capable systems on the intranet, the client side application on the DirectAccess client must be IPv6 capable. If the client-side application is not IPv6 capable, it must use a non-DirectAccess method to reach the application server, such as an Internet accessible application gateway.
In the context of connectivity to SAP resources, you had to use an alternate method outside the DirectAccess tunnels before the release of SAP GUI version 7.1. With the introduction of SAP GUI 7.1, the DirectAccess client can connect to SAP resources on the intranet over the DirectAccess tunnels. However, to get this to work, you need to set a specific environment variable, which we will discuss later in this post. This solves the IPv6 problem on the client side.
If the SAP server is not IPv6 capable (meaning that it isn’t using ISATAP or native IPv6 addressing), then the UAG DirectAccess server’s NAT64/DNS64 feature will be used for IPv6/IPv4 protocol translation. While this will allow access to a SAP server, it will break SAP load balancing. The end result is that if you don’t need SAP load balancing, then all you need is to do is set the environment variable on the SAP GUI client and connectivity will work over DirectAccess because NAT64/DNS64 will take care of the protocol translation for you.
However, if you need load balancing for your SAP servers, NAT64/DNS64 isn’t going to do all the work. In this case you’re going to need to bring in another component, called a SAPRouter.
A SAProuter is a non-transparent gateway that can accept both IPv4 and IPv6 connections and do protocol translation between IPv4 and IPv6. NAT64/DNS64 are not used. Instead, the DirectAccess client connects to the SAPRouter using the SAPRouter’s IPv6 address, and then the SAPRouter can route the connections to the IPv4-only SAP servers behind the SAPRouter. At this point the SAP servers are able to load balance the connections and also return the responses to the SAPRouter, which is then able to return the responses to the DirectAccess clients through the UAG DirectAccess server.
Figure 1 illustrates the request/response path between the DirectAccess client and the SAP resource servers (note that the load balancing component of the SAP servers is called out to make the path easier to understand).
The following are instructions should configure the SAP GUI 7.1 client to work with DirectAccess:
If you are using a saprouter you would have to add an entry in the field "SAProuter String", for example "/H/saprouterxy".
If you have further questions regarding this issue, please write to the address in the sig line below.
Authors:
Noam Ben-Yochanan, Senior Program Manager, DA
DirectAccess is a new remote access technology enabled by the combination of Windows Server 2008 R2 and Windows 7. Unlike other remote access technologies such as reverse proxy, reverse NAT, SSL VPN gateways, and network layer VPNs, the goal of DirectAccess is to extend your network to any location in the world, so that your domain member client systems are always connected to the corpnet.
Think about the mix of remote access technologies you use now. Some of them might be in place to support partners, for which you want to provide very limited network access. But what about your employees? If you’re like me, you’ve probably spent most of your professional life trying to figure out how to give employees the information they need, in the most efficient way possible, so as to create the least frustration for both the employee and the Help Desk and IT overall. Most of all, you want to make sure this access is secure and that security doesn’t interfere with productivity.
There have always been two major stumbling points when providing productivity-enabling remote access to employees:
When you think about it, neither you nor your users ever wanted to use VPN. You never really wanted your employees to have to use SSL VPN gateways. You never actually wanted your users to have to gain access to resources over reverse proxies and NAT devices. You never really wanted to use any of the myriad number of remote access “artifices” that you’ve put in place.
But you did, because your goal was to provide your business an advantage by delivering out of office users access to information so that they could get their work done from anywhere.
But these solutions didn’t really didn’t do what they were supposed to do – at least not for you and your employee users:
No, we didn’t want these remote access solutions for our employees, but they were the best we could do.
What we actually wanted all this time was DirectAccess.
I can tell you that as a user, DirectAccess becomes a transformational experience. It completely changes the way I approach my work. In the past, if I left the office, I anticipated the traditional road warrior’s “negotiations with the remote access gods”.
The negotiations went something like this:
You just never knew what the computing experience was going to be. If the network layer VPN worked, then almost everything worked. Of course, I’d have to fire off the VPN client first, and make sure the client was configured correctly (easy for me, not so easy for the average or even above average user). If neither network layer VPN protocol worked, then I spend my time living the second-class life of browser based applications. And file access experiences ranged from problematic to catastrophic.
There were often workarounds, but I could employ them because I’ve been doing networking for a long time. Average users would give up, call the Help Desk or try their best to do what they could with what they had – with the end result being a significant compromise in productivity and a flagging faith in the entire remote access experience and reduced expectations for what could be done when away from the office.
DirectAccess changes the game. Not only the game, but the entire playing field. So many of the problems related to remote access technologies that I’ve described so far are due to the users “location awareness”. While location awareness in the software is a very useful thing (and used by DirectAccess in the background), it’s not something you and your users want to worry about.
It’s the entire “location awareness” issue that creates problems for users:
This “location awareness” creates both conscious and unconscious friction with the surface of user productivity. Energy is wasted and productivity is reduced. With DirectAccess, the entire “location awareness” issue is a non-issue. When you and your users connect with DirectAccess – the experience is the same all of the time.
How is the computing experience the same in each of these scenarios? Because the following describes the computing experience for all five of the scenarios listed above:
Notice there was no “starting the VPN connection” or “connecting to the SSL VPN portal page” or anything else that required the user to be “location aware”.
This is what makes DirectAccess the paradigm shifting, transformational technology it is. And what really proves the point is how quickly you will take it for granted. That is a key component of what I consider to be transformational technology – you take it for granted because it was always supposed to be this way. In fact, you’ll find that the technology, over time, will seem boring to you. And for new computer users who have never experienced DirectAccess , they will find it really boring – or at least not exciting or transformational, because they will assume that is how remote computing should have always been done.
The story on the IT side of the house is just as compelling. Now you have access to the DA clients anytime a DirectAccess client is turned on; the user doesn’t even need to be logged on. You can apply patches, do “just in time” updates, install software, remove software, perform real-time remote management and configuration or assistance over RDP, and many more management tasks because the connection between DA clients and management servers is bidirectional and always available between the management servers and DA clients.
Your DA clients will be in the same state of compliance as machines that never leave the corpnet and they have access to all the management, command and control systems you use to manage any machine on the corpnet.
The reason is that DirectAccess allows you to extend the corpnet and its management infrastructure to the DA client.
I know that you’ve heard about “paradigm shifts” and “transformational technologies” in the past. IPsec server and domain isolation had that potential. But it never caught on. Network Access Protection, something I can remember hearing a number of people at TechEd 2004 demand “I need it now!” But after it was released, sort of “hung in the stretch” (to use a horse racing term). Why? I don’t know if there are any official reasons why, but I suspect that these two fantastic, potentially game changing technologies were just too complex and the expected return on investment for dealing with such a level of complexity ended up being too low.
This can’t and must not happen to DirectAccess – there are two main reasons why I don’t see DA “dying on the vine”:
So there you have it – my reasons why DirectAccess will change the world, and it’s a world that both IT and end-users have always wanted to live in.
It’s also a world that I want to help you get to. In the following months this blog will be dedicated to UAG DirectAccess and provide you hints, tips, tricks, ideas, opinions, workarounds, designs, and experiences that will speed your path to DirectAccess deployment. Because the only way you’ll really know the joy of the DirectAccess experience is to experience it. And after that, you’ll take it for granted – but you’ll be taking for granted an all new world of computing – one that allows you to get more done faster without ever needing to think about where you are.
Thomas W. Shinder MD
Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)
(Updated Oct 5, 2010)
I’ve seen a number of questions asking if there was a method you could use to migrate your Windows DirectAccess configuration to a UAG DirectAccess deployment.
The answer to this question is that there is no automated method to do this. However, the manual steps aren’t very difficult. Here’s what you need to do:
That’s all there is to it!
Now you can install UAG on the server that you had configured as the Windows DirectAccess server, or you can install UAG on a completely different server.
Let me know if you run into any issues with your migration from Windows DirectAccess to UAG DirectAccess. If this scenario is popular enough, I’ll put together a Test Lab Guide that demonstrates the process!
(Thanks to Yaniv Naor for the heads up on this)
(Thanks to Pat Telford for the information included in the update)