Microsoft Forefront Unified Access Gateway Product Team Blog : DirectAccess

Deep dive into UAG DirectAccess (Manage Out Basics)

edgeaccessblog — Tue, 17 Nov 2009 08:44:00 GMT

Today, I’m just going to be brief for a change, and discuss what we refer to as “Managed Out” scenarios.

I want to thank Pat Telford a consultant in Microsoft, specializing in DirectAccess deployments among other things, for helping with this subject.

Like I mentioned in one of my first posts, one of the big advantages of the DirectAccess technology over traditional VPN service is that DirectAccess clients can be managed anytime they are connected to the Internet. We like to refer to that scenario as “manage out.” This means that the client’s computer is “always managed” – there is an IPsec channel that enables the infrastructure and management servers to have access to the client’s computer, even when a user is not logged on.

There are two ways manage out can be accomplished:

Client-initiated: Where the DirectAccess client initiates the communication to a server on the intranet, and then “pulls” it down:

In this case the intranet server can be an IPv4 server, and UAG DirectAccess uses it's NAT64/DNS64 capabilities to compensate for the lack of IPv6 connectivity to the intranet server
The following are examples of Client-initiated management traffic:

System Center Configuration Manager
Windows Server Update Service
System Center Operation Manager (Most of the time)
Updating Anti-Virus definitions
Applying Group Policy Objects

Intranet -initiated: Where the resource in the intranet initiates the communication to a DirectAccess client on the Internet:

The host initiating the connection must be able to determine the IP address of the remote DirectAccess client. This means that the Remote DirectAccess client must register its FQDN and IPv6 address in the internal DNS servers.

The client can register its IPv6 address dynamically, if dynamic DNS updates are enabled, and the DNS server supports AAAA records.
The DNS server must be reachable from IPv6 DirectAccess clients. If you aren’t routing native IPv6 in your network, you can use an ISATAP generated IPv6 address for the DNS server.
Using a Windows Server 2008 or Windows Server 2008 R2 based DNS Server is the best option here, since they natively support both of the above.
The second best option would be to use Windows Server 2003 DNS servers With UAG DirectAccess. The built-in NAT64/DNS64 will still provide connectivity to IPv4 only DNS servers.

UAG DirectAccess supports using NAT64/DNS64 to register DirectAccess clients on a Windows 2003 Active Directory infrastructure.

The host initiating the connection must be IPv6 able – Our NAT64 implementation doesn’t translate connections initiated from the intranet.
The following are examples of traffic that is initiated by resources inside the intranet:

Protocols that may be used by IT personnel (“Peer to peer”)

Remote Desktop
SMB – for reaching out to files on the user’s machine

Endpoint vulnerability scans

That’s all for today, just remember, if you have protocols that initiate connections to DirectAccess clients, you’ll need the DNS infrastructure to be set correctly for it to work with UAG DirectAccess. In addition, don’t forget to specify relevant management servers in the Management Servers and DCs page in the Forefront UAG DirectAccess Configuration Wizard, if you want managed out communications between the client and the management servers, even when the no one is logged on to the client computer.

Thanks

Ben Bernstein

Deep dive into UAG DirectAccess (Certificates)

edgeaccessblog — Tue, 27 Oct 2009 13:33:00 GMT

I hope you survived my last blog post about IPv6. Today I’m joined by a fellow member of the UAG team: Max Braitmaiere, who is a software design engineer in the UAG DirectAccess team, Max designed many of the UAG DirectAccess specific features.

Let’s discuss today the certificate configuration in UAG DirectAccess.

Let’s go over the difference between the two certificate configuration items that are requested when UAG DirectAccess is set up.

PKI, IPsec and DirectAccess

As you’d expect, DirectAccess protects the tunnels between the DirectAccess client and the UAG DirectAccess server. DirectAccess uses IPsec for that purpose, specifically AuthIP. If you want to read more about AuthIP, here is a nice article about it by the Cable Guy. AuthIP enables using two levels of authentication, and DirectAccess leverages that, but for the purpose of this post we’ll focus on the first authentication – which requires the use of digital certificates in the local computer store as issued by a PKI. For successful certificate authentication in DirectAccess, the two IPsec endpoints need to trust a common entity – a root or intermediate certification authority (CA) in the certificate path of the CA that issued the certificates.

Although DirectAccess could have configured IPsec to accept any trusted root or intermediate CA, to be more secure DirectAccess uses a specific, single, common root or intermediate CA, which is trusted by IPsec on both the client and the UAG DirectAccess server. So, when you run the UAG DirectAccess Configuration, you need to specify the common root or intermediate CA that both the client and the server trust by selecting its certificate. If you “Browse” you’ll get the list of trusted CA certificates, and you can select one.

<<Figure 1: A snapshot from UAG’s IPSec CA certificate selection page>>

Since the trusted CA certificate list in the UAG machine is separated to “root” folder and “intermediate” folder, you have the option of picking either a root CA certificate, or an intermediate CA certificate.

<<Figure 2: A snapshot of the MMC snap-in for managing certificates>>

Please note that the CA certificate list consists of “public” certificates – certificates without a private key (the private key is a well guarded secret which the CA uses for signing the certificates it generates). The certificates in the Personal folder of the computer store however, usually contain a private key, and are used by the user for authentication, signing its communications and encrypting data.

You must ensure that both the DirectAccess client and the UAG DirectAccess server have a certificate in their local computer certificate store (as seen in the Personal folder in the Certificates snap-in) that was issued by a CA that has a path to the selected root or intermediate CA certificate (see the Certificate Path tab for the properties of the certificate in the Certificates snap-in). The certificates on the DirectAccess client and server should contain a private key and the Client Authentication object ID (OID) in the Enhanced Key Usage field to support IPsec authentication.

An advanced note: If there is more than one certificate on the client computer, IPsec prefers certificates that contain the IP security IKE Intermediate OID. If there is a health certificate on the client computer for NAP (that contain the system health OID), it is preferred over the IP security IKE Intermediate certificate.

Another advanced note: Certificate revocation list (CRL) checks on the certificates can be configured using netsh and or Group Policy (in netsh advfirewall set global ipsec strongcrlcheck 0|1|2. By default, the value used (for both the server and the clients) is 1 which means that CRL testing is done, but if any error occurs during the CRL validation, the certificate is accepted.

PKI, IP-HTTPS and DirectAccess

IP-HTTPS is a tunneling technology that enables the DirectAccess clients to connect over IPv4. The DirectAccess server publishes a Web service over SSL and acts as an IP-HTTPS server (for more information about IP-HTTPS, see protocol specification).

The certificate configuration is a little different – here you must pick a specific certificate for IP-HTTPS to use:

<<Figure 3: A snapshot from UAG’s IP-HTTPS certificate selection page>>

If you press the “Browse” key you would get a list of certificates from the Personal folder of the UAG DirectAccess server’s computer certificate store. The certificate you pick MUST have a private key (moreover – all array members must have this certificate with the private key).

The certificate in this case should be a regular Web server certificate, which means it should have the Server Authentication OID in the Enhanced Key Usage field.
(If you have a certificate with both Client Authentication and Server Authentication OIDs it can be used for both IPsec and IP-HTTPS).

Here again you should make sure that the client trusts the certificate, but trust is not limited to a specific root/intermediate CA like it is in the IPsec case. The client must trust the root CA that issued the IP-HTTPS certificate.
Regarding CRL, unlike IPsec, the client’s default in this case is “strong” check, which means that if the CRL distribution point is not available on the Internet, the client cannot validate the IP-HTTPS certificate and will fail in establishing SSL connection.

Summary

There are two types of certificates involved when you deploy DirectAccess: IPsec certificates, and Web certificates. Each one has a different configuration mechanism. To configure UAG DirectAccess you are required to pick the certificate of a root or intermediate CA that is in the certificate path of the CA that issues the DirectAccess client and the server IPsec certificates, and you are also required to pick a Web certificate to be used for IP-HTTPS.

Thanks

Max Braitmaiere

Ben Bernstein

Deep dive into UAG DirectAccess (IPv6 and DirectAccess)

edgeaccessblog — Tue, 13 Oct 2009 13:12:00 GMT

Technorati Tags: uag - Unified Access Gateway,DirectAccess,IPv6,DirectAccess and IPv6,IPv6 prefixes,NAT64,DNS64

Ok, this time it’s going to be a long dive, hold your breath :)

I’ll skip my usual grandiose introduction, since there are many things I want to share today…

NAT64 and DNS64 on video

Oh, a quick note before I start, I had a discussion about UAG and DirectAccess with Stephen Bowie, which was recorded on TechNet Edge. If you’re looking for a little more information about the NAT64, DNS64 and other value added by UAG, you should check out this link (sorry about my haircut, I wasn’t aware this will be public :))

DirectAccess and IPv6

DirectAccess uses IPv6 for remote access. The reason behind it is that DirectAccess tries to look two steps ahead when thinking about remote access. Given the fact that public IPv4 addresses are running out, let’s consider the following scenario (outlined in the figure below). We have a client that is in one private network (in our case it contains S2 and Client), and it needs to have seamless remote access to another private network (in our case, the other network contains S1). Because both networks are using the same private IPv4 address space, IPv4 traffic is not routable between them, so we have an irresolvable conflict (In a classic IPv4 VPN scenario, the client can manually chose to connect to a VPN to access S1, but that is not seamless access).

In DirectAccess since the client is IPv6 based, it can access both S1 and S2. That is possible because from an IPv6 point of view all machines have unique IPv6 addresses. When the private network containing S1 is behind a UAG DirectAccess server (which is acts as a NAT64) the client would access S1 using S1's globally unique IPv6 address (intercepted by the NAT64). Local resources such as S2 would be accessible using IPv4 (or IPv6 if the network is IPv6 compatible). Here as you can see the client seamlessly accesses the network containing S1.

I’m not saying that the world will move instantaneously to IPv6, but when you plan remote connectivity for your organization you might start thinking about integrating IPv6 enabling technologies such as DirectAccess.

This is why today I want to focus on the how DirectAccess relates to IPv6 addresses in your organizational network.

A quick introduction to IPv6 addresses

I guess IPv6 is a very long subject which can’t be fully addressed in a blog post. I do however want to give a quick introduction to IPv6 addresses and prefixes. IPv6 addresses and prefixes were the hardest part for me when I moved to the DirectAccess realm. I just had to start looking at IPv6 addresses. I was quite shocked by the fact that they were 128 bits long, and I still have trouble comprehending this.

A useful thing I learned was that for many practical reasons for unicast addresses, you can look at the first 64 bits of an address and learn a lot. The rest of the bits, are well, less important… To be more specific, a given subnet is represented by the first 64 bits, the next 64 bits represent a computer in that given subnet.

When I look at the first 64 bits of a unicast IPv6 address inside an organization network I can usually categorize it into one of the following:

(The list below refers to prefixes. Prefixes are a list of hexadecimal digits, separated by colons, and followed by a forward slash, and the number of high-order bits in the prefix, pretty much like IPv4 subnet definition, e.g. 192.168.17.0/24 means the first 24 bits set to 192.168.17 (converted to binary) and 2002:836B:1::/48 means the first 48 bits equal 2002:836B:0001 (converted to binary).)

1. 2002:WWXX:YYZZ::/48

This is called 6to4 address space

It means you own a public IPv4 address, and you're using it to generate a 6to4 prefix.

WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, which is the public IPv4 address you must own.

It also implies you have (somewhere) a Window-based server that owns that w.x.y.z, which has assigned itself the following IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ

That server is called a 6to4 router.
It has a 6to4 router mechanism that enables it to route IPv6 traffic over the IPv4 internet using its IPv4 address (w.x.y.z).
Advanced note: If that server has other means of connecting to the IPv6 Internet, it is called a 6to4 relay.

The UAG DirectAccess Server acts as a 6to4 router and relay, and in some cases uses the 6to4 48-bit address space for addressing (I will explain shortly)

2. FD00::/8 (called unique local addresses, works according to the following RFC)

This means that the owner generated a random 48-bit IPv6 address space (he picked a random 40 bit number and appended it to FD00::/8)

Although these addresses are legal, they are not globally routable, and do not provide connectivity with the IPv6 Internet.
You can configure UAG DirectAccess to work with these types of addresses, but using these addresses is only recommended in a lab environment, rather than for long term deployment.

3. FE80::/64

This is a link-local address, which is used between machines on the same subnet.
If these are the only IPv6 addresses you have on a machine – the chances are that the machine isn't talking IPv6 with anyone :), at least not outside its subnet.

4. 2001:0::/32

A client with such a prefix received its address from a Teredo server, which probably means it doesn't support native IPv6 connectivity.

E.g. My home machine (ISPs here don’t support IPv6 yet), Hotels, etc…

Organizations usually don’t use these addresses internally, since by default Windows-based Teredo clients do not use Teredo on a managed intranet…
UAG DirectAccess uses this address space for DirectAccess roaming clients. It acts as a Teredo server for them.

5. Other public IPv6 prefix (usually 48-bit, which usually represents a single organization)

The prefix should have been assigned by IANA or a local Internet service provider.

A quick “advanced” note – 6to4 and Teredo clients use 6to4 addressing and Teredo addressing. IP-HTTPS clients, ISATAP hosts, and servers behind a NAT64 don’t use a specific address schema, so when these technologies are configured, a specific prefix should be configured for them. Such a prefix is usually allocated from one of the existing schemas: 6to4, unique local, or public (options 1, 2, and 5 above).

So, when you configure UAG DirectAccess you need to configure a prefix for the NAT64, ISATAP hosts (if ISATAP is configured), and for the IP-HTTPS clients.

How UAG configures DirectAccess IPv6 prefixes

When running the UAG DirectAccess configuration you pick the Internet facing and internal facing IP addresses.

When the Connectivity screen is displayed, behind the scenes UAG DirectAccess actually checks to see if you have IPv6 address on the internal facing UAG interface. If you do, it disables the Internal IPv4 address list box, if you don't it disables the Internal IPv6 address list box, however a lot more happens behind the scenes.

No IPv6 address on your internal facing UAG interface.

If you have an IPv4 address on the internal facing interface, DirectAccess assumes that you don’t have IPv6 deployed in your organization. It then uses the internal IPv4 address to configure the UAG DirectAccess server as an ISATAP router. If you use this option please note that Windows-based ISATAP hosts in your network can't use ISATAP until you register a DNS record of ISATAP (e.g. ISATAP.internal.contoso.com) in the DNS server (mind the Global Query Block List). Once you register the ISATAP name, Windows-based ISATAP hosts in your organization start using IPv6 and use the UAG DirectAccess server as their ISATAP router.

Behind the scenes UAG DirectAccess automatically configures the following prefixes using 6to4 notation:

2002:WWXX:YYZZ:8000::/49 as the organizational prefix
2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

An “advanced” note – the reason that /49 address space is used, is that the 6to4 address 2002:WWXX:YYZZ::WWXX:YYZZ is used for IPSec tunneling and cannot be part of the organizational prefix.

If there is an IPv6 address on your internal UAG interface.

This might be useful in cases where you:

Need a more advanced IPv6 deployment in your organization.
Want more control over the address allocation for remote access.
Are deploying a lab with a single subnet, where you use static IPv6 addresses.

If you had an IPv6 address on the internal facing interface, on the prefix configuration screen you need to enter three different IPv6 prefixes.

Organization prefix

Here you allocate an IPv6 prefix using one of the options mentioned above (public, 6to4, or unique local) and go with it.

Since UAG DirectAccess uses the 6to4 server addresses to terminate IPsec tunnels, the 2002:WWXX:YYZZ::/48 prefix can’t be used as your organization prefix as it contains the UAG’s 6to4 addresses. You should use a 2002:WWXX:YYZZ:8000::/49 prefix in such a case.

In UAG RC0 you cannot specify a /49 prefix, please see a note below for a work around.

IP-HTTPS prefix

Here you specify a prefix with a length between 56 to 64 bits.

If you plan to deploy a single server you can use /64. If you plan to deploy an array, you should allocate a wider range. See the UAG documentation for more information.

NAT64/DNS64 prefix

You allocate a specific 96-bit prefix for your legacy IPv4 servers. The DNS64 adds an appropriate 32 bits, creating a 128-bit IPv6 address using the IPv4 address of the server.

Note ISATAP is not needed if an IPv6 address is present on the internal facing interface, hence no ISATAP prefix is required.

A work around for using 6to4 prefix in RC0

In UAG RC0 you are required to specify a 48-bit prefix for your organization. If you decide to go with 6to4 addressing, you should configure a third public IPv4 address on the Internet interface of the UAG machine (let's say w.x.y.t). After you do that a third 6to4 address is generated on the 6to4 interface of the UAG DirectAccess server. The new IPv6 address (2002:WWXX:YYTT::WWXX:YYTT) isn’t used for IPSec tunnel termination, and you should now use the new 2002:WWXX:YYTT::/48 prefix as the corporate 48 bit prefix.

An “advanced” comment: The reason the third public IPv4 address needs to be on the UAG Internet-facing interface, is so that DirectAccess 6to4 clients that want to access the organization 6to4 prefix, will try to connect to the IPv4 address derived from the 6to4 prefix (in our case w.x.y.t), and we need the UAG to listen for 6to4 traffic on that IP address.

Wrapping Up

So we had a little introduction to IPv6, how and why DirectAccess leverages that, and some drill down into how and why IPv6 prefixes are configured when you configure DirectAccess

OK, you can breathe again :).

Leave a comment below if you think there are more topics you want me to relate to.

Ben

Deep Dive Into DirectAccess – NAT64 and DNS64 In Action

edgeaccessblog — Tue, 08 Sep 2009 23:14:00 GMT

In the previous posts my colleague Ben provided an overview of Forefront UAG DirectAccess and its NAT64 and how it is different from NAT-PT. In this post I will show a step-by-step example of how UAG DirectAccess NAT64 and DNS64 work together to provide DirectAccess users access to IPv4 machines on the corporate network.

Step 1: Client DNS query

It all starts when the DirectAccess client sends a DNS query to the UAG DNS64 to get the address of an application server. It is important to note that DirectAccess clients have connectivity to the corporate network only over IPv6, therefore their DNS queries are always IPv6 DNS queries that are called “AAAA” (quad A). For more details on DNS resolution with IPv6 see here.

All clients’ DNS queries for corporate destinations are assigned to UAG DNS64 because UAG alters the clients’ Name Resolution Policy Table (NRPT) via its group policy. For more explanation on how NRPT works, see here. The NRPT table is configured with the list of corporate domains (“contoso.com” in the example below) and the DNS associated with them. It is configured in the DNS suffixes page in the UAG DirectAccess infrastructure servers wizard.

In our examples “contoso.com” is the domain suffix, 2002:c00a:a02::c00a:a02 is the DNS64 address and “inout.contoso.com” is the network location server:

In the first step of the example, the client tries to find the IP address of a server called x.contoso.com:

Step 2: DNS64 query

After it got the query from the client the UAG DNS64 sends two DNS queries: an IPv4 query (A query) and an IPv6 query (AAAA query) to the corporate DNS. UAG locates the corporate DNS servers based on its own DNS configuration.

Step 3: DNS Response

After DNS64 gets the responses from the corporate DNS server it decides which address to return to the client:

If DNS64 got in the response an IPv6 address (AAAA Response) then the application server has IPv6 connectivity so DNS64 returns this address to the client. Please note that there are cases where the DNS64 will get both IPv4 and IPv6 address. In these cases, it will return the IPv6 address.
If DNS64 got in response only an IPv4 address it is assumed that there is only IPv4 connectivity to this server and therefore NAT64 will have to bridge all traffic. Since the client needs an IPv6 address DNS64 generates an IPv6 address from the IPv4 address based on the NAT64 prefix configured on the UAG DirectAccess prefixes page.

In this example, x.contoso.com is an IPv4 only server that needs NAT64 to bridge all traffic:

UAG screen where the NAT64 prefix is configures:

Tip: If there is a server that has IPv6 connectivity but its applications do not support IPv6 and therefore it needs NAT64 to bridge all the traffic, you could either disable its IPv6 interfaces or prevent the DNS from returning its IPv6 address from the corporate DNS.

Step 4: Client sends packets to server

Now after the client machine has the address of the application server, it starts sending data packets to this server. The packets are sent to the UAG DirectAccess NAT64 since all IPv6 addresses that are included in the NAT64 prefix are routed to UAG DirectAccess.

Step 5: NAT64 forwards the packet using IPv4

NAT64 receives the data package and tries to determine the IPv4 address that is associated with the destination IPv6 address. Then it creates a new IPv4 packet that has the same payload and sends it to the application server.

For the application server, the origin of the IPv4 data packet is the UAG server. If UAG DirectAccess is deployed in high availability and scalability mode on an array with integrated Windows Network Load Balancing (NLB), the packet’s origin would be the internal device IPv4 address of the node that handled the traffic. In that case, when the application server replies to this packet, it will reach the node that interacts with the client.

Meir Mendelovich

Senior Program Manager, UAG Product Group

Deep Dive Into DirectAccess - Part 2

edgeaccessblog — Thu, 27 Aug 2009 15:23:00 GMT

Hi,

My name is Ben Bernstein and I’m a Program Manager for the Forefront Unified Access Gateway (UAG) team.

This is a follow up blog post to the blog post I recently made.

“Do Do Do DA DA DA is all I want to say to you” (Gordon Sumner)

I hope you are intrigued by DirectAccess (DA). Today I’m going share with you some thoughts about the value Forefront Unified Access Gateway DirectAccess adds to the Windows 2008 R2 DirectAccess offer.

“If you can’t change the world. change yourself. And if you can’t change yourself....change the world” (Matt Johnson)

You can think of UAG as “glue”, not just for the DirectAccess scenario, but for many other scenarios. UAG in my eyes is a vehicle for delivering new identity and access related technologies.

Let’s go back to the way UAG incorporated DirectAccess technology and specifically how it added to it the ability on the UAG DirectAccess server to connect to IPv4-based resources.

As you might have read in my previous post, DirectAccess is based on IPv6 technology. While this enables some cool features in regards to how clients tunnel their way to the UAG gateway, it poses a challenge since most organizations today don’t have an IPv6 ready intranet.

To make the Windows DirectAccess technology support IPv4 based servers, UAG implements a technology called NAT64/DNS64.

NAT64 (pronounced “NAT six to four”) is a component that is broadly based on the IETF memo. It enables initiating communication from an IPv6 based network to an IPv4 based network. In many ways I think of it as a subset of the NAT-PT capabilities that are relevant to the DirectAccess scenario.

For NAT64 to work it needs to utilize another component called DNS64 which is also based on the IETF memo. DNS64 is a DNS server on the UAG server which “multiplexes” DirectAccess clients DNS requests for IPv6 records into two DNS requests, one for IPv4 records and one for IPv6 records. If IPv6 DNS records exist they are sent back to the client. If there are none, then IPv4 records are translated into “fake” IPv6 records - owned by the NAT64 device. When a DirectAccess client tries to access them, it actually uses NAT64 addresses.

If you are wondering how the client queries the DNS64 instead of its regular DNS server, it is quite simple. Like all other client configurations, that configuration is also set using group policy. Group policy tweaks the Name Resolution Policy Table (NRPT) settings. NRPT settings tell the client to send DNS requests with a specific DNS suffix to a given DNS server. Type “netsh name show policy” on the client to see what NRPT settings exist.

“One is the loneliest number that you’ll ever do” (Aimee Mann)

One is definitely a lonely number, especially as a point of failure. What I mean is that once you have DirectAccess working, you probably want to examine two important aspects of deploying any service: scalability and fault tolerance. UAG in general and UAG DirectAccess solution specifically supports having both of these by utilizing Windows Network Load Balancing (NLB) technology. The great thing about this technology is that it doesn’t require additional hardware. You just decide the number of servers you want to use, and that is it. The way to deploy multiple servers in UAG is to create an array of UAG machines. In the DirectAccess scenario, you create such an array and then turn on UAG’s NLB to add scalability to DirectAccess and to make it fault tolerant.
An interesting side note is that we needed to tweak Windows NLB a little for it to work with UAG DirectAccess. The IPsec state of a client, needs to stay on a single machine and that meant that all traffic to and from a specific client needs to stick to a specific UAG array member. So we created some tweaks so that traffic initiated from and to corporate resources by the DirectAccess clients, stick to the UAG array member which “owns” the client (this challenge is sometimes referred to as “bi-directional affinity”). The component that enables this functionality is a UAG driver called “Microsoft Forefront UAG DirectAccess NLB Helper” and nicknamed “daeng”

I’ve seen the end of the day come too soon … Rest a day, for tomorrow you can’t tell… (Beck Hansen)

The bottom line is that these three mechanisms (DNS64, NAT64, and the NLB driver) enable UAG to utilize DirectAccess technology more fully, and enable a smoother deployment of the DirectAccess technology…

See you next time

Ben

Deep Dive Into DirectAccess - Part 1

edgeaccessblog — Mon, 27 Jul 2009 12:55:00 GMT

Hello,

My name is Ben Bernstein and I’m a Program Manager for the UAG team.

As a follow up to Nitzan’s blog post DirectAccess support in UAG, I want to share with you some additional thoughts.

Broadband internet connections have been commoditized to a point where anyone can use a 3G broadband connection from a laptop for a reasonable price, and possibly use Wi-Max or similar technologies in the future. I believe this process will create a growing need for business laptops to become “always connected”. Given that, I also believe that DirectAccess will become a very handy technology.

For me, getting into the office early in the morning is a challenge; traffic congestion is a nightmare around here. However, I just learned a new trick from a colleague of mine. Whenever he gets stuck in traffic he pulls over and uses his 3G USB stick to work seamlessly as if he was actually in the office, and when traffic clears he gets back on the road. Luckily, our internal DirectAccess deployment enables him to work seamlessly, as if he is directly connected to our corporate network. He practically does everything from his laptop - mails, IM/VOIP, access to internal web sites and file shares, Terminal Services to his workstation, code check-ins - everything!

Most of you are probably raising an eye-brow right now and asking “What does DirectAccess add on top of our existing VPN solution?” I guess there are several answers, but for me the two important points that are inherent in the DirectAccess design are “Separation of user identity and machine identity”, and “Strong client side tunneling technologies”.

“Separation of user identity and machine identity” – DirectAccess technology is based on IPsec tunneling, where the traffic is split into two IPsec tunnels. One tunnel deals with machine based traffic, including services that make the machine “Always managed”/”Always up to date”. Another tunnel deals with user based traffic. This separation enables a given machine to be fully “IT accessible” whenever it is switched on and connected to the internet. It also enables a more sophisticated scenario in which the machine is fully “IT accessible” at all times, but only when users present a smartcard, do they get access to the corporate resources.

“Strong client side tunneling technologies” – DirectAccess technology uses IPv6 network connectivity, behind the scenes. IPv6 provides two great tunneling technologies which are being used in DirectAccess and are part of Windows Server: Teredo and IP-HTTPS. These two technologies enable DirectAccess clients to connect to the gateway even if they are behind a NAT device or behind a router that opens up only port 443.

There are many other aspects of the DirectAccess deployment I’d like to share with you - such as how are configuration settings provisioned to DirectAccess clients? (in short “group policy”). Do I need to make IPv6 related infrastructure/server side changes to support DirectAccess? (in short ,NO. UAG supplies NAT64 on box). How one can make DA highly available, scalable, etc... using UAG? (in short, UAG supports both Windows Network Load Balancing, and external Load Balancers). But … traffic has cleared I have to go J… so you will have to look out for my next blog post…

Thanks

Introducing UAG DirectAccess solution

edgeaccessblog — Mon, 22 Jun 2009 08:09:00 GMT

As the PM lead responsible for the UAG DirectAccess, I’m proud to present our solution based on the new and exciting technology introduced by Windows 7 Direct Access. If you want to learn more about this technology click here.

Microsoft Forefront Unified Access Gateway (UAG) utilizes DirectAccess technology built into Windows 7 and Windows Server 2008 R2 to create an enterprise level solution. UAG offers an all in one, end-to-end solution that lets the enterprise open its resources to managed clients in a seamless, painless manner.

UAG DirectAccess extends access to IPv4 servers

In order to support all backend servers, UAG DirectAccess adds a necessary transition technology (NAT64 and DNS64 also known as NAT-PT and DNS-ALG) to also allow clients access to IPv4 only servers – in addition to IPv6 based servers (natively or via ISATAP).

UAG DirectAccess enhances scalability, high-availability and management

Our solution adds the ability to scale and have multiple Direct Access Servers (DAS) in a cluster for providing high-availability of the service as well as scale-up. As part of ‘all in the box’ paradigm, UAG integrates Windows Network Load Balancing (NLB) support that could be seamlessly activated for the cluster.

UAG DirectAccess simplifies deployment and administration

We incorporated and augmented the DirectAccess configuration into its Unified Access Gateway management console allowing an easier deployment of the cluster. The console will help you setup, configure, activate and manage the cluster and each node in it from a central location. This console can be used to enforce policies (such as NAP and Smartcard), set IPs, etc.

UAG also provides access, from within the same cluster, for down level and non Windows clients

As its name suggests, Unified Access Gateway provides multiple access scenarios for managed remote clients (via UAG DirectAccess) as well as unmanaged, or even ‘foreign’ remote access clients in a secure way. By utilizing various remote access technologies, UAG can publish business server applications to unmanaged clients enforcing various authentication methods.

Nitzan Daube

Principal Program Manager Lead, UAG product group.