Microsoft Forefront Unified Access Gateway Product Team Blog : UAG - Unified Access Gateway

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

Load Balancing Backend Servers Farms

edgeaccessblog — Mon, 16 Nov 2009 15:34:00 GMT

Applications that are published using UAG can benefit from its built-in load balancing functionality. Multiple backend servers can be configured per application, and Web Farm Load Balancing (WFLB) will take care of distributing traffic across the different servers and maintaining clients’ affinity.

Let’s assume I am publishing Outlook Web App (OWA). There are two Client Access Servers in my Exchange 2010 deployment, EX14-CAS-01 and EX14-CAS-02. My trunk’s public host name is portal.contoso.com, but instead of using that I would like users to access OWA using mail.contoso.com. Considering the published OWA application is consumed by a Web browser, I can improve the experience with cookie-based affinity; distributing traffic across the array in a more evenly manner (avoiding the problem with forward proxies of multiple users behind the same IP address). All of these configuration settings are reflected in Figure 1:

Figure 1 - Exchange Web Farm Configuration

The above illustrates a plain vanilla scenario. In contrast, some farms tend to be pickier on how they are being approached. For instance, they may require the Host: name in the HTTP header request to point to the farm’s name instead of a particular backend server. You can instruct UAG to do that by selecting the Use the farm name in the HTTP check box and specifying the designated farm name in the Server farm host name edit box. UAG also replaces backend farm links that match the content of this edit box with the public host name. Figure 2 illustrates how to bake all of this into WFLB configuration settings.

Figure 2 – Advanced Farm Configuration

With the above settings, UAG HTTP requests to backend farm servers look as follows:

GET / HTTP/1.1
Host: partners.contoso.com (instead of Host: EN-RWS-01 or EN-RWS-02)

Content from backend servers that contains references with EN-RWS-01 will be modified, as UAG will replace them with partners.contoso.com. Effectively, end-users will not be exposed to the internal hosts’ names but to the public host name only.

Michel Biton

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

Forefront UAG Release Candidate 0 (RC0) is here!

edgeaccessblog — Fri, 25 Sep 2009 21:00:00 GMT

So we promised you RC0... Now it's here! Check out the previous post to read a bit about the new features we introduced.

Click to get the bits:

Download

We value your thoughts and ideas

Your feedback is important to us! We use it to continue improving our product so that it will best serve your needs. You can provide feedback through our forum. You might notice some of the feedback you gave us on the beta is already incorporated into UAG :).

Some tips to get you started:

Go over the release notes.
Read the system requirements, installation guidelines, and the DirectAccess step-by-step installation instructions.
Make sure you have Windows Server 2008 R2 RTM Standard or Enterprise version
Start playing around and getting to know the new features using a single server, and afterwards scale up to multiple servers in an array.
If you want to migrate a Beta 2 configuration to RC0, after running Setup, run the Microsoft patch file (.MSP) that's included in the download.

For additional questions visit our TechNet forum. Follow us on our blog too; we're planning on providing you with lots more information on features and how to get it up and running.

Have fun!

Forefront UAG RC0 is on its way…

edgeaccessblog — Tue, 22 Sep 2009 19:34:00 GMT

From the producers of Forefront UAG Beta, we're proud to present you with (drum roll…)

Forefront UAG Release Candidate 0!!!

Over the last couple of months we've been listening to your feedback and working on incorporating it into UAG.

We put an increased focus into improving overall product quality, and streamlining and simplifying the initial deployment experience.

Here's the shortlist of some highlights you'll find in RC0:

· Import/Export - Use the new import/export capability to backup your configuration. You can even export an array configuration and import it into a standalone machine.

· SCOM - The UAG management pack monitors health aspects of critical components of UAG & DirectAccess services, enables centralized viewing of important UAG events and alerts on the SCOM console, and supports array-level views for easier monitoring of complex deployments.

· Simpler array management - Now it's even simpler to deploy and manage your array from the Forefront UAG management console.

· Publishing Exchange – We added Web Services to the out-of-the-box publishing experience, with full support for NTLM and Kerberos authentication.

· Remote Desktop - Support for Remote Desktop publishing and single sign-on through the UAG portal.

And there is more, much more…

Forefront UAG RC0 will be available for download over the next couple of days. Stay tuned for more news and updates about the new release.

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

Considerations for Exchange Publishing

edgeaccessblog — Mon, 10 Aug 2009 23:51:00 GMT

UAG does a great job of streamlining secure messaging, with a publishing experience that is framed into a set of easy to follow steps. Nonetheless, before you start there are a couple of considerations to bear in mind:

Choosing between a dedicated mail trunk or mail applications contained in a UAG portal
Selecting Exchange mail applications available to end-users
Deploying the authentication method that is right for your organization

Dedicated Mail Trunk or a UAG portal

Having a dedicated mail trunk means a designated FQDN (e.g. https://mail.contoso.com/) that will serve mail applications, exclusively. This can be very convenient for end-users, regardless of their device or platform - ActiveSync on a mobile device, Outlook client or Outlook Web Access – mail is served using a single domain name. However, you will need a certificate for this FQDN that will reside on both UAG and the Exchange Client Access Server.

Figure 1. Dedicated Mail Trunk

Instead of having a dedicated mail trunk, you may wish to go with a UAG portal (e.g. http://access.contoso.com/). Such a portal is used as a container, with Exchange as one of many other applications. In the following example, SharePoint is published alongside Exchange.

Figure 2. Portal Containing Outlook Web Access and SharePoint

What impact will a portal have on messaging user-experience? For one thing, Outlook Web Access will be contained inside a portal frame, with no need to re-login when SSO is used. For OutlookAnywhere and ActiveSync the experience is identical to a dedicated mail trunk, with the portal playing no role in their interactions.

Selecting Exchange Applications

Ultimately, the published mail applications are a derived choice of end-points’ devices and company policies. UAG public beta covers Outlook Web Access, ActiveSync and OutlookAnywhere. What is missing? Exchange Web Services. We plan on adding full support to their out of the box publishing in the UAG release candidate.

Figure 3. Choose Exchange Applications on UAG Beta

You can either select to publish all applications at once, or run the wizard multiple times, one per desired application. Why would you do the latter instead of the former? Well, since each time you publish an application you have the opportunity to specify back-end parameters, this gives you the flexibility to use a different back-end configuration per Exchange application. For example, use cookie-based affinity for Outlook Web Access and IP-based affinity for OutlookAnywhere.

Figure 4. Setting Back-end Affinity

Choosing an authentication method

Many factors influence selection of an authentication method, as on-top of the technological considerations, you have regulation, policies and end-users’ experience.

UAG does offer a wide variety of authentication methods. Using the public beta you can deploy basic pre-authentication or 2 factor authentication, while the release candidate is planned to extend that with NTLM authentication against the gateway (and Kerberos constraint delegation against the Exchange Client Access Server).

Figure 5. Exchange Applications Authentication on UAG Release Candidate (RC)

Conclusions

Forefront UAG represents a step forward in satisfying inbound access needs of organizations. Particularly, we have invested heavily in Exchange publishing scenarios, providing a wide range of ways to accomplish secure messaging. However, you do need to share the action with us, making the choices that are right for your enterprise prior to engaging the deployment.

Michel Biton

Faster, Higher, Stronger – UAG Performance

edgeaccessblog — Sun, 02 Aug 2009 21:41:00 GMT

Everybody’s always talking about performance, but what does it really mean? In this post I’m going to describe some of the behind-the-scenes work we’ve been doing on UAG performance.

Performance improvements are a major area of focus for this release. First and foremost, in UAG we switched to 64-bit architecture, thus overcoming the address space limitation that existed in the 32-bit architecture. In addition, we invested in reducing CPU and memory consumption in major scenarios, establishing and verifying system settings for maximum capacity, and more. For example, one of the recent improvements is utilizing the port scalability feature of Windows in RPC over HTTP(s) scenarios.

Outlook clients tend to use relatively large number of connections with the server (an average of 15-20, and up to 30 connections per outlook client). Using the port scalability feature enables us to utilize several IPs between the UAG and the backend server thus significantly enlarging the number of available ports. This will enable concurrent publishing for significantly more Outlook clients.

Test methodology and testing tools

So how does the UAG product team validate system performance? Our performance testing environment is comprised of an end-2-end Microsoft environment, including physical UAG servers, Exchange backend, Active Directory/Domain Controller; and load generators that simulate end-user machines. The idea is to simulate the customer environment as closely as possible, including Web Farm Load Balancing (WFLB) towards the backend, array/load balancer configuration on UAG, etc.

Some of the tools we use for UAG performance improvements and testing:

· Exchange Load Generator (LoadGen) is a load testing tool developed by Microsoft Exchange team. Customers can use it to test UAG (and of course Exchange) performance in their environment prior to deployment. LoadGen supports various mail protocols; we use it to simulate Outlook Anywhere publishing.

· Avalanche appliance by Spirent Communications was used to simulate Web Publishing (e.g., OWA).

Avalanche console

Performance test example

We've been running performance and stability testing for quite a long time. As an example, here are some results of one of stability tests we ran in preparation for the UAG Beta release.

Test environment:

· 2xUAG machines in array/Windows Network Load Balancing configuration

· Exchange 2007 backend with 2 Exchange CAS servers (with WFLB load balancing), HUB, mailbox store

Test scenario: load on each UAG server:

· 1K concurrent Outlook Web Access (OWA) users (54 Mbps throughput)

· 2K concurrent Outlook Anywhere/RPC over HTTP(s) users

Test length: 72 hours

Typical test environment

The observed test results were as following:

End-user response times (collected by Avalanche, for OWA test):

Action	Response time (sec)
Get Logon Page	0.187
Login	0.706
Inbox	0.905

UAG server resources utilization (collected from UAG server performance monitor):

UAG performance statistics example

What’s next?

This is just a first glance on the UAG performance story. We’re working on further optimizing and verifying UAG performance and scalability towards our release candidate (RC) and the release itself, enhancing the performance tests with additional scenarios (e.g., ActiveSync), and more. Stay tuned!

Olga Levina

Program Manager, UAG Product Group

Contributors: Asaf Kariv, Dima Stopel, Oleg Ananiev

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

Comparing UAG and TMG arrays

edgeaccessblog — Mon, 20 Jul 2009 21:28:00 GMT

Judging from a number of newsgroup posts, there is some confusion about differences and similarities between TMG Beta 3 arrays and UAG Beta 2 arrays. So I thought a quick summary might be useful:

TMG Beta 3 comes in two flavors – Standard edition and Enterprise edition. Enterprise edition provides the following types of arrays:

Enterprise array
Standalone array

UAG Beta 2 uses the standalone array topology provided by TMG. UAG has no concept of an Enterprise array.

So what's the difference between the array types?

A TMG enterprise array uses an Enterprise Management Server (EMS) – a server that is installed on a separate box. The EMS is used for centralized management of an enterprise array or arrays (and can also be used to manage single TMG servers). You can add TMG servers to an enterprise array by connecting them to the EMS. On the EMS, you can create enterprise policies that are applied to enterprise arrays managed by the EMS.
A standalone array, on the other hand, has the following characteristics:

It does not require a separately installed server for array management.
It consists of multiple single UAG server peers that are joined together into an array configuration.
All UAG servers that are members of the standalone array share the same configuration – for UAG this includes the same portals, published applications, permissions, VPN settings etc.
Although array configuration is shared, a few server-specific settings continue to be maintained, including certificates and passwords
A standalone array with NLB enabled supports up to 8 array members.

So how does a standalone array work?

One of the array members operates as the designated array manager.
The array manager stores the configuration settings for all array members, and the server-specific settings for each array member.
To configure a server as member of a standalone array, you join it to the array manager.
To create a new array you do the following:

Add the UAG server that you want to join to the array to the TMG Managed Server Computers computer set. Do this from the TMG Management console running on the array manager (the UAG server that you intend to join the server to).
Run the Array Management Wizard on the UAG server that you want to join to the array.
During the wizard, you select the UAG server that you want to join to in order to form the array.
The UAG server that you select to join to becomes the array manager.

So what can I do with a standalone array?

You can join single servers to an array. After joining the array and activating, the joined server inherits the array configuration and the original server settings are no longer applied.
In the Array Management Wizard, before joining the array, you can choose to specifically back up server settings to an export file before joining an array. This is useful if you want to restore a specific configuration if you later remove the server from the array.
You can remove a server from an array so that it reverts to behaving as a single server with no array dependencies. When you disjoin the server from the array, the following occurs:

If you do not restore server settings from an exported file, the disjoined server will revert to using its local settings that were disabled when you joined the array.
If you specifically backed up server settings when you joined the array, you can select to restore the settings from this exported backup file, or from any other backup file.
If you want to continue to use the array settings on the server after it is disjoined from the array, you will need to export the settings before disjoining from the array, and then restore the server settings from this export file. Note that this option isn't supported for Beta 2.

You can modify the array member that is designated as the array manager.
If the array manager is modified, you need to run run the Array Management Wizard on each array member to make sure that each server is aware of the new array manager.

So what should I know before I start?

· As with all beta versions, there are issues you should be aware of before beginning an array deployment. The release notes have all the known issues at http://technet.microsoft.com/en-us/library/dd772157.aspx.

Where can I read more?

· For UAG, there's a planning guide for arrays and NLB over at TechNet (http://technet.microsoft.com/en-us/library/dd861476.aspx)

· For UAG array deployment information, take a look at http://technet.microsoft.com/en-us/library/dd857305.aspx

· Also, take a look at Asaf Kariv's blog post at http://blogs.technet.com/edgeaccessblog/archive/2009/06/29/array-and-network-load-balancing.aspx

· If you're using UAG DirectAccess, take a look at http://technet.microsoft.com/en-us/library/ee191502.aspx for information about array configuration

· For TMG, take a look at http://technet.microsoft.com/en-us/library/dd440989.aspx

Cheers!

Rayne Wiselman

Forefront UAG UE team

Feedback to uagdocs@microsoft.com

Note that this is a new alias and you may not yet be able to send mail to it. We are expecting the alias to be up and running some time during the next 24 hours - thanks!

What’s in UAG for the end-users

edgeaccessblog — Sun, 19 Jul 2009 23:28:00 GMT

In this blog we usually talk about the technologies, how to get better/easier/simpler connectivity, how to simplify deployments and manage them easily. Still, we hardly ever talk about what matters most, the people we really care about – our end users, remote workers who are using UAG to get access to their corporate resources, from anywhere. At the end of the day, everything we do is done especially for them.

In UAG, we’ve given quite a lot of thought to the end user experience. We wanted to make life really easy and simple for them (at least the remote access bit of their life). The first thing you’ll notice when you access UAG from a client machine is the new portal. We changed and updated the portal look & feel. More importantly, we added new features such as search and sort to make it easier to find the applications.

We wanted to make sure our end-user receives the best service, no matter which device is used to access the portal. When accessing UAG, the user is automatically redirected to the correct portal, based on the device they’re using. We have 4 different portals: 2 for PCs and 2 for mobile devices. The portal is supported on Internet Explorer, Firefox and Safari. For other browsers, we offer a limited version of the portal. Below are screenshots from the Beta portal.

Portal for PC (supported browsers)

Limited Portal for PC (unsupported browsers)

Portal for PDA and Smartphones

Limited Portal for All Mobile Phones

Another great enhancement is that UAG beta supports clients from all locales. That means you can access UAG from any localized machine and still get the same service.

As UAG is progressing toward its general availability, you can expect even more changes and improvements in the client side. Stay tuned…

Forefront UAG Beta 2 Docs

edgeaccessblog — Tue, 14 Jul 2009 12:43:00 GMT

Along with the Forefront UAG Beta 2 download, the UAG user experience (UE) team has launched a brand new UAG content library over at TechNet (http://technet.microsoft.com/en-us/library/dd861463.aspx). This content is designed to help you plan, deploy, and maintain your UAG servers, and is organized as follows:

Evaluation - In the Evaluation section you can read an overview of UAG features, and for existing IAG and UAG users, you can get a quick summary of What's new in UAG Beta 2.
Getting Started - Read about last minute issues in the release notes. Especially important before you install and deploy!
Planning and Design - Our Planning and Design guides are designed to help you understand how you can meet your organization's deployment goals with a UAG solution, and how to plan for that solution.
Deployment - The Deployment section helps you to get UAG installed, and to set up your deployment infrastructure. It includes a Deployment Checklist, System Requirements; Installation instructions; DirectAccess deployment steps; instructions for deploying an array of multiple load-balanced UAG servers; setting up client authentication servers; and client endpoint deployment and access policies.
Operations - Operations provides information about configuring portals and published applications, and configuring file access and client VPN (SSL Network Tunneling) access. The Operations guides also includes a series of Application Publishing Solution Guides, providing a one-stop shop for the information required to publish common applications, including SharePoint, Exchange, Dynamics CRM, and Remote Desktop Services (Terminal Services).

We'd love to hear your feedback about our UAG TechCenter content - what we're doing right - what we can improve - feedback about your search experience - and any other suggestions you might have. You can contact the user experience team directly at uagdocs@microsoft.com.

Cheers!

Rayne Wiselman - UAG Content Team

Ready, Set, Download! Forefront UAG Beta is here!

edgeaccessblog — Tue, 14 Jul 2009 00:02:47 GMT

Over the last couple of weeks we've been talking quite a lot about the Forefront UAG beta. Finally, you can experience it for yourself! We have been working feverishly to bring you all the new features and technologies, wrapped up in one box. Click the big download button below to get the bits:

We can't wait to hear your thought and ideas

Your feedback is truly important! We use it to continue improving our product so that it will best serve your needs. You can provide feedback through our forum. Please remember this is still a work in progress, we have more coming up as we move towards final release.

Some tips to get you started:

Go over the release notes.
Read the system requirements, installation guidelines, and the DirectAccess step-by-step installation instructions.
Start playing around and getting to know the new features using a single server, and afterwards scale up to multiple servers in an array.
Configure each new remote access feature, and explore it before adding others.

For additional questions visit our TechNet forum. Follow up on our blog too; we're planning on providing you lots more information about the new features and how to get it up and running.

Have fun!