(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.

If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.

For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.

The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.

As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.

The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.

So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.

However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.

But this begs the question: is DA split tunneling really a problem? The answer is no.

Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is  not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.

Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.

HTH,

Tom

Tom Shinder
Microsoft ISDUA
Anywhere Access Team/UAG DirectAccess

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

An interesting case came in last week and I thought it would be useful to share it with you all. It’s especially interesting because it covers some not so well documented features of the IP-HTTPS client configuration and how it works.

For those of you who haven’t worked with DirectAccess, or who are in the process of learning about it, IP-HTTPS is a new protocol introduced with Windows 7 and Windows Server 2008 R2 for Microsoft DirectAccess that allows a DirectAccess client to connect to the DirectAccess (DA) server by using HTTP (SSL) as a transport. This enables the DA client to connect to the DA server even when the client is located behind a firewall or web proxy that only allows outbound HTTP/HTTPS.

In this example, the admin had a problem with getting IP-HTTPS connectivity to work. As part of his troubleshooting process, he ran the command

netsh interface httpstunnel show interface

The results were:

Role                       : client

URL                        : https://da.domain.com:443/IPHTTPS

Last Error Code            : 0x103

Interface Status           : no usable certificate(s) found

The problem seemed to be related to the interface status: no usable certificate(s) found.

When the admin checked whether there was a computer certificate installed on the computer, he saw that there was, so it didn’t make sense that there was no usable certificate. Perhaps there was something missing from the computer certificate itself?

To understand the problem, it helps to understand how the computer certificate is used in establishing the IP-HTTPS connection. The DA IP-HTTPS client uses the computer certificate to establish the IPsec tunnel,  just as it does when it’s acting as a 6to4 or Teredo client. However, when acting as an IP-HTTS client, the computer certificate is also used to provide credentials for client authentication when connecting to the IP-HTTPS listener on the DA server.

Client certificate authentication is a default setting on the UAG DA server when the client connects over IP-HTTPS, but it is not a default setting on the Windows DA server. If you want to require client certificate authentication to the Windows DA server (which protects the IP-HTTPS listener against denial of service attacks) you can configure the setting manually by using the information in the article Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections. These instructions will enable the DS Mapper usage feature on the DA server. However, keep in mind that if you are using a UAG DA server, you do not need to do this – the UAG DA wizard takes care of this configuration for you.

You can confirm that DS Mapper Usage is enabled by using the netsh http show sslcert command on the DA server, as seen in the figure below.

Notice the title of that article. Not only does the setting configure Client Authentication, but it also configure Certificate Mapping.

What is this certificate mapping of which I speak?

If you look in Active Directory Users and Computers and right click on a DA client computer account, you will see the Name Mappings option in the context menu, as seen in the figure below.

After selecting the Name Mappings option, you’ll see the Security Identity Mapping dialog box, as seen in the figure below. Here you see that the mapped user account (which is mapped in the Active Directory) is to domain1.corp.company.com/Computers/CLIENT2.

This name maps to the DNS name assigned to the computer account, which you can see in the Properties dialog box of the computer account, as seen in the figure below.

In order for client certificate authentication to work, the subject name or a SAN on the certificate must match the DNS name assigned to the computer account. For example, in the figure below you can see that the first SAN shows the DNS name of the computer, which is the same DNS name used by the computer account for this DA client computer.

So what could cause this problem? It might be that the certificate template used to create the computer certificate didn’t include DNS name of the computer account in the subject name or the first SAN. If you use the default Computer certificate template, you will see that the DNS computer name is used as the subject name in the certificate, as shown in the figure below.

(Note: the certificate above is from a different client computer than those shown in the other figures, that’s why it shows CLIENT1 instead of CLIENT2).

However, if you use a custom certificate or another certificate template to assign the computer certificate, you will need to configure the template so that the DNS name of the computer is included in the subject name or in a SAN entry.

For example, look at the Properties dialog box for the Workstation Authentication certificate template. On the Subject Name tab, you can select the option Build from this Active Directory information option and then select your preferred Subject name format. If you don’t choose the Common Name or DNS Name option, then you’ll want to make sure that the DNS Name checkbox is selected from the Include this information in alternate subject name list. In fact, even if you choose the Common Name or DNS name option, it’s not a bad idea to select the DNS name entry for the first SAN, as there are scenarios that require this.

It is important to note that this is one of the reasons why you want to use an Enterprise CA in your environment, so that this AD mapping takes place automatically. When the UAG DA server receives the computer certificate from the DA IP-HTTPS client, it will use the DNS name to forward to the domain controller for authentication. If this name does not match the name associated with the computer’s account, authentication will fail.

CONCLUSIONS:

• On the Windows DA server, client certificate authentication is not enabled by default for DA IP-HTTPS clients
• On the UAG DA server, client certificate authentication is enabled by default for DA IP-HTTPS clients
• When client certificate authentication is enabled on the DA server, the client must provide a computer certificate to authenticate to the DA server’s IP-HTTPS listener
• The subject name or a SAN on the computer certificate must include the DNS name listed for that computer account in Active Directory
• If the computer certificate does not include the DNS name of the computer, as listed in AD, in its subject name or SAN entry, then you will see that the Interface status will state that there is no usable certificate(s) found after running the netsh interface httpstunnel show interface command
• If you create a custom certificate template to computer certificates for your DA clients, make sure you include the DNS name to be included in the subject name or a SAN name.

Let me know if you have any questions on this and I’ll follow up in another blog post.

[Props to Billy Price for coming up with this solution]

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
MS ISD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

When you configure a Windows DA server or UAG DA server-based DirectAccess (DA) solution, the default setting is to enable split tunneling. What split tunneling refers to is the fact that only connections to the corpnet are sent over the DA IPsec tunnels. If the user wants to connect to resources on the Internet, the connection is made over the local link (that is to say, the connection is sent directly to the Internet based on the IP addressing configuration on the DA client computer’s NIC).

The advantage of split tunneling is that users have a much better computing experience, especially when accessing Internet based resources. In addition, users on the corpnet are likely to have a better computing experience when accessing resources on the Internet, since the DA client traffic isn’t consuming corporate Internet bandwidth to connect to Internet resources. The combined advantages of improved DA client and corpnet client Internet computing experience makes it worthwhile to make split tunneling the default configuration for DA client/server communications.

Disable Split Tunneling by using Force Tunneling

However, you might not want to enable split tunneling. If that is the case, then all traffic from the DA client to any resource must go over the DA IPsec tunnels. Traffic destined for the intranet goes over the DA IPsec tunnels, and traffic destined to the Internet also goes over the DA IPsec tunnels. Split tunneling is disabled when you enable Force Tunneling for the DA client connections. Force Tunneling is enabled via Group Policy:

Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network

When Force Tunneling is enabled, all traffic is sent over the DA client tunnel using the IP-HTTPS protocol. IP-HTTPS is one of the three IPv6 transition protocols that the DA client can use to connect to the DA server. The other two protocols are 6to4 (used when the DA client is assigned a public IP address) and Teredo (used when the DA client is assigned a private IP address and has outbound access to UDP port 3544 to the DA server). IP-HTTPS is used when the DA client is assigned a private address and outbound access to UDP port 3544 to the DA server is not available.

The Problems with IP-HTTPS

The problem with IP-HTTPS is that it should be considered, and is instantiated as, a protocol of last resort. There are a number of reasons for this, with the primary reason being that it’s the lowest performing of the IPv6 transition technology protocols. Think about it – the client and server have to negotiate and use IPsec encryption and then also has to negotiate and encrypt the HTTPS (SSL) session. This “double encryption” takes a toll on the processor. In addition, IP-HTTPS has a much higher protocol overhead, so that the area available for the payload for each packet is smaller, requiring more packets to be sent to communicate the same amount of data, thus impairing performance even more.

In addition to the performance issues are the Internet access issues for the IP-HTTPS client. Remember that all communications from the DA client to the DA server are over IPv6. The DA client never uses IPv4 to connect to resources through the DA client/server channel. Because of this, you will need to deploy an IPv6 aware web and winsock proxy server on the network that the DA clients can use to connect to the Internet, or use the UAG DirectAccess solution, which includes an IPv6/IPv4 protocol translator that allows the DA client to connect to Internet resources through a IPv4 web and winsock proxy server, such as the ISA or TMG firewall. This adds more complexity to an already problematic situation.

And there is one more “gotcha” when you use Force tunneling. As I’ve said, all communications between the DA client and server are over IPv6. What this means in practice is that the client application must be IPv6 aware. This is not to say that the server side of the application needs to be IPv6 aware and in most cases the server side will work fine with the help of the UAG NAT64/DNS64 IPv6 protocol translator if the server side is only IPv4 aware – but the client side must always be IPv6 capable.

Thus, Force Tunneling can be a problem in those scenarios where the client side is not IPv6 aware. For example, the Office Communications Server Client (at the time of this writing) is not IPv6 aware. In order for the DA client to reach the OCS server, it will need to use the direct connection to the Internet to connect to the OCS server located on the corpnet. If you try to force the OCS client/server communications over the DA connection, the attempt will fail because the OCS client is not IPv6 aware. Any other non-IPv6 aware client application will fail, as it won’t be able to connect over the Internet because split tunneling is disabled.

Split Tunneling Issues and Considerations

At this point it’s worthwhile to think about split tunneling and the reasons why you wouldn’t want to enable split tunneling to determine if those reasons are actually applicable in a DA client/server solution. It might turn out that the assumptions you made when deciding against split tunneling weren’t as valid as you thought, and that the perceived risks of split tunneling were overstated to the extent that split tunneling may no longer be an issue.

Most network admins developed their opinions regarding split tunneling based on their understanding of how VPN clients work, and in many (most?) cases these opinions were derived from issues that were extant in the early to mid 1990s and with non-Microsoft VPN clients.

What are some of the reasons why you think you need to disable split tunneling? Two of them might include:

• Network security policy requires that all client traffic must go through the corporate web proxy and clients are never allowed to connect to the Internet directly.
  If this is the case, you need to make sure that users aren’t local administrators of their laptops, since a local administrator can disable the Force Tunneling configuration. In addition, you need to be aware that even when Force Tunneling is enabled, users are able to connect to resources before the DA connection is enabled. For example, DA client connections can’t be enabled if the client doesn’t have Internet access, and in some cases the client needs to connect to a portal to get that Internet access – so there is some degree of access available even before the DA client/server connection is established.
• You think that disabling Force Split Tunneling will protect Internet bound traffic since it has to go over the DA connection to reach the Internet
  If this is the reason to disable split tunneling, then it’s not a good one, since the traffic sent to the Internet through one of your corporate proxies to the Internet it as susceptible to detection and interception as any other Internet communication once it leaves your proxy, .

Now let’s examine the relationship to VPN and split tunneling, since this is usually the basis for wanting to disable split tunneling:

• With a VPN configuration, when split tunneling is disabled, users must connect to the Internet over the VPN link. But when the user disconnects from the VPN, that user is able to directly connect to Internet resources. This means that you are comfortable with having that user access the Internet without gateway inspection from time to time – and more likely most of the time, since users typically only connect to the corporate VPN when they need to.
• If the previous is true, then your primary concern is that split tunneling is undesirable because there is some perceived security issue with having a user connected to both the Internet and the intranet (over DA) at the same time.

So the question at this point should be “what are the problems with allowing users to connect to the Internet and the intranet at the same time?” – as this appears to the crux of the split tunneling issue.

• The first issue that most VPN administrators are concerned about when it comes to split tunneling is the prospect of an Internet intruder somehow “routing” a connection from the Internet through the DA client into the intranet. The problem with this reasoning is that it would require bridging to be enabled on the DA client computer, which is not something enabled by default. This prevents any of the forwarding that the VPN admin might be concerned about. You can even use Group Policy to make sure that the user cannot enable connection bridging, assuming that the user even knows how to do this.
• The second issue relates to malware that is run on the VPN client computer. Perhaps the malware is a network worm that can spread to the intranet, or some other type of malware that can gain access to information on the corpnet and bring it to the VPN client. Perhaps the malware could even enable bridging.
• Regarding the second issue, turning off split tunneling does not solve this problem. When you allow clients to connect to the Internet, or to any non-filtered device (USB key, DVD, CD, etc) you have the same risk regardless of whether split tunneling is enabled or not.
• Another thing when considering the second issue is that the software industry as a whole has become very good at dealing with situations where a network is unavailable for a period of time. The malware writers also know this and their code is just as effective in these scenarios. Malware can check-in on a periodic basis to see if there is something accessible on the corpnet, it doesn’t depend on an “always on” connection to be effective. So, the malware checks to see if the intranet is available, when it is, it grabs the information it’s looking for. Then after the VPN connection is dropped, the malware can connect to its “master” over the local connection to the Internet. Again, disabling split tunneling did nothing to prevent this problem.
• Force Tunneling is a more complex solution, and can limit access to resources required by your users. Do the perceived benefits of disabling split tunneling really make up for the productivity losses due to lack of resource access?
• Force Tunneling will be more expensive, since you’ll need to increase the bandwidth available to Internet connections, and scale up your proxy server deployment to handle the additional traffic. You also need to factor in the additional operational costs against the marginal (if any) benefits gained by disabling split tunneling
• Enabling Force Tunneling could reduce Internet accessibility, because there are more components in the path between the client and server. Incremental losses of productivity per user could end up being significant when factored over the entire population of users.

Conclusion

From this assessment, it seems clear that there is only one valid scenario where you would want to disable split tunneling and that’s when you want to force all traffic through the corporate web and/or winsock proxy server so that the traffic is filtered to reduce the risk that malware can be downloaded to the DA client over the Internet. I admit, that if there is a weak link in the DA story, that this is it.

However, this weak link isn’t a DA issue because the fact is that there are no longer any “bolted down” corpnet clients. Most organizations have moved to laptops for their employees, and those mobile devices travel between the Internet filtered corpnet and the non-filtered Internet on whatever external network those clients are connected to. Therefore, unless you’re using a 3rd party solution that enforces Internet access policy to computers that aren’t connected to the corpnet, there is little to be gained by forcing the DA clients over the corporate web filters. Of course, the ideal situation would be to use an Internet based web filtering solution so that the DA clients have corporate web access policy forced on them as well.

Another thing that should be clear at this point is that the issue of “routing” communications from an Internet based host to the corpnet doesn’t happen on Windows clients of today. So that concern, perhaps inherited from the 1990s, is no longer an issue and doesn’t represent a security issue for VPN or DirectAccess clients. Whether the client is connected intermittently (as with VPN clients) or is “always on” (as with DA clients) really doesn’t make a difference in terms of the overall security posture provided by the DA client.

In sum, I highly recommend that you do not disable split tunneling for your DirectAccess clients. The benefits from doing so are virtually none, but the cost, complexity and productivity hits imposed by enabling Force Tunneling can be substantial.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

(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:

• ISATAP – stands for the Intrasite Automatic Tunnel Addressing Protocol. The UAG DA server will set itself up automatically as an ISATAP router and provide your IPv6 aware hosts IPv6 addresses and routing information. ISATAP capable hosts include Windows Vista and above and Windows Server 2008 and above. What do you need to make this work? Not much. Enable your DNS servers to answer queries for ISATAP, enter ISATAP Host (A) records on your DNS servers, and make sure IPv6 is enabled on your network hosts (it’s on by default, but some people turn it off). That’s it! Now all your IPv6 hosts on the network have IPv6 addresses, and you didn’t have to do anything other than run the UAG DA wizard, configure the DNS server a little bit and not turn off IPv6 to make it work. No IPv6 jockey license required. Oh, and one more thing, since ISATAP tunnels IPv6 packets within an IPv4 header, routing within your IPv4 infrastructure will work just fine, no changes on your IPv4 routers required. None, not any.
• 6to4 – is a IPv6 transition technology that the DA clients and UAG DA server can use to connect the DA client to the UAG DA server over the IPv4 Internet. 6to4 is used when the DA client is assigned a public IP address. The IPv6 packets are encapsulated in a IPv4 header and send over the 6to4 tunnel adapter to the DA server. What do you need to do to make this work? On the client, nothing – it works automatically after you run the UAG DA wizard and have Group Policy applied to the DA client. On the server – again nothing. Just run the UAG DA wizard and apply the Group Policy to the DA server and it works. Again, you can know nothing about IPv6 transition technologies and it just works. IETF membership not required.
• Teredo – is another IPv6 transition technology that enables the DA client to connect to the DA server over the IPv4 Internet. In this case, Teredo is used when the DA client is located behind a NAT device (either a NAT router or a NAT firewall) and the device allows outbound UDP port 3544. If the DA client has a private IP address and outbound access to UDP 3544, then the DA client uses Teredo to encapsulate the IPv6 messages from the DA client to the UAG DA server in an IPv4 header to send over the IPv4 Internet. What do you need to do to make this work? Like with 6to4, just run the UAG DA wizard, apply the Group Policies, and the DA client and UAG DA server are automatically configured to use Teredo. Holy Toledo!
• IP-HTTPS – is yet another IPv6 transition technology that allows the DA client to connect to the UAG DA server over the IPv4 Internet. IP-HTTPS is a “last ditch” method to encapsulate the IPv6 packets in an IPv4 header. When the client is assigned a private IP address, and the NAT device or firewall is configured to allow only HTTP/HTTPS outbound, then the DA client falls back to IP-HTTPS. The reason why we consider IP-HTTPS to be a “last ditch” effort is that yout users are going to find IP-HTTPS connections to not be quite as “performant” as 6to4 or Teredo connections (assuming that they’ve been paying attention). This makes sense when you think about adding SSL to the already existing IPsec computational efforts and the extra protocol overhead involved with using HTTP as the transport. What do you need to do to make this work? Ha! Nothing – the UAG DA wizard creates the configuration, creates the Group Policy settings and all you need to do is wait for the Group Policy settings to be applied to the DA clients and UAG DA server and away you go. No muss, no fuss.
• NAT64/DNS64 – NAT64/DNS64 (pronounced NAT 6 to 4/DNS 6 to 4) is a cool little piece of technology that the UAG team put together so that you can get DA working with the software assets you likely have running today. If I had to bet a quarter, I’d say that not everything on your network was IPv6 capable (that is to say, capable of running native IPv6 addressing or act as a ISATAP host). That would include all those Windows 2000 and Windows 2003 Servers you have on the network (yes, I know quite a few of you are still running Windows 2000). Since neither Windows 2000 nor Windows Server 2003 are IPv6 capable, you need a little help to get them to work with DirectAccess. No problem! NAT64/DNS64 accepts the connections from the DA client, automatically creates a IPv6 address for the name requested by the client, and then does a “NAT” kind of protocol transformation so that the IPv6 communication from the DA client is forwarded to the IPv4 only server on the network using IPv4. The response is returned to the DA server, which translates the IPv4 response into an IPv6 message that is returned to the DA client. Nice! But what do you need to know, what do you need to do to make this work? Enable two checkboxes in the UAG DA wizard. That’s it.

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.

HTH,

Tom

Tom Shinder

tomsh@microsoft.com

Microsoft ISDiX\Anywhere Access Team

UAG DirectAccess

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

When you run the configuration wizard on the UAG DirectAccess (DA) server, one of the things it does is create Group Policy Objects (GPOs) and Group Policy Settings in those GPOs. After the UAG DA server creates the GPOs and configures the settings, it can automatically deploy these settings into your domain. These settings are linked to the root of the domain that the UAG DA server belongs to. There are three GPOs created by the DA wizard, as seen in the figure below.

These GPOs are:

• UAG DirectAccess: AppServer {GUID} – these GPO settings are applied to machines that you include in the application servers groups, which are called out at the end of the UAG DA configuration wizard. These policies enable end to end IPsec protection between the DA client and the destination server.
• UAG DirectAccess: Client {GUID} – these GPO settings are applied to the DA clients. DA clients are assigned to a security group that you create when you configure the DA solution for your organization. There is no “built in” DA clients security group, you need to create this yourself.
• UAG DirectAccess: DaServer {GUID} – these GPO settings are applied to the UAG DA servers themselves. If you have a single UAG DA server, then these settings will be applied to that server. If you have an array of UAG DA servers, then the GPO settings will be applied to each of the servers in the UAG DA server array.

Group Policy assignment uses GPO Security Filtering to assign the GPO settings to the correct machines. In the figure below, you can see that I’ve selected the UAG DirectAccess: DaServer {GUID} policy in the left pane of the console. In the right pane, in the Security Filtering section, you can see that the policy is applied to the machine accounts of the two UAG DA servers participating in a UAG DA high availability array.

Security Filtering is also used to assign the GPO settings to the DA clients. In the figure below you can see that I’ve selected the UAG DirectAccess: Clients {GUID} GPO. In the right pane of the console you can see in the Security Filtering section that the GPO is applied to members of the DA_Clients (CORP\DA_Clients) security group. Keep in mind that DA is made available to computers, not users. Therefore, you need to put the computer accounts into the security group you’ve designated for your DA client computers. After you create the security group, add the computer accounts to that group. Then the DA Clients GPO settings will be applied to those machines.

It’s critical that you apply the Group Policy settings to the correct computer accounts and groups. If you apply the DA Clients GPO settings to the wrong computers, some very bad things can happen, such as name resolution failing throughout your network in some scenarios. There can be many unintended effects if you apply the settings to all authenticated users or any of the built-in security groups included in Active Directory, such as the Domain Computers security group.

If you find that you’ve applied the GPOs to the wrong computers, and end up with problems with network connectivity or name resolution on your network, I want to recommend to you that you call Microsoft Customer Support Services (CSS). While there are some things I can recommend to you that might help fix the problem, there are too many different scenarios where this problem might find itself so that a generic solution is unlikely to be useful in your case.

The UAG DA wizard will assign the correct GPO settings to the right computers if you made the correct selections in the wizard. For more information on how to use the UAG DirectAccess wizard, check out the UAG DirectAccess Deployment Guide at http://technet.microsoft.com/en-us/library/dd857320.aspx

HTH,

Tom Shinder
“The Edge Man”
tomsh@microsoft.com
Microsoft ISD iX
UAG DirectAccess/Anywhere Access Team (AAT)