AppWrap (Application Wrapper) is an IAG and UAG XML configuration file that enables manipulating HTTP responses on their way back from the backend web server to the client.

In IAG 2007, approximately 30 such files existed, since each AppWrap file was used for a different type of single-application trunk (for example, one AppWrap file was used for a trunk publishing Outlook Web Access 2003, and another AppWrap file for a trunk publishing Outlook Web Access 2007), as well as for portal trunks.

Since single-application trunks are not used in UAG (with the exception of publishing an Active Directory Federation Server), we are left with one main AppWrap file, which is the one used for portal trunks (two versions of this file exist – for HTTP and HTTPS trunks – but they are very similar).

After removing a large amount of manipulation configurations, the files became much clearer and maintainable, as their size was reduced to about 1/3 of their size on IAG 2007.

Manipulation per application

The AppWrap structure was changed to support manipulation per application:

Each group of <DATA_CHANGE> tags is enclosed within <APPLICATION_TYPE>[APP_TYPE]</APPLICATION_TYPE> tags, where APP_TYPE represents the application ID defined in the top part of WizardDefaultParam.ini and then inside []. For example, [ExchangePub2007].

It is still possible to define an empty APPLICATION_TYPE as follows: <APPLICATION_TYPE></APPLICATION_TYPE>, for any other manipulation for a non-defined application.

This change greatly improved the “search & replace” manipulation mechanism and thus enhanced performance.

Backward compatibility

In order to port IAG-style AppWrap files to the UAG format, some manual changes of the original file are needed: after the <MANIPULATION> tag, add a <MANIPULATION_PER_APPLICATION> tag, immediately followed by an <APPLICATION_TYPE>[APP_TYPE]</APPLICATION_TYPE> tag.

Remember to add a closing </MANIPULATION_PER_APPLICATION> tag after all the <DATA_CHANGE> sections, right before the <HEADER_CHANGE> section begins.

The changes are highlighted below.

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

          <MANIPULATION>

                  <MANIPULATION_PER_APPLICATION>

                          <APPLICATION_TYPE>InternalSite</APPLICATION_TYPE>

                          <DATA_CHANGE>

                                  <URL case_sensitive="false">…</URL>

                                  <SAR>

                                          <SEARCH encoding="base64">…</SEARCH>

                                          <REPLACE encoding="base64" using_variables="true">…</REPLACE>

                                  </SAR>

                        </DATA_CHANGE>

                       …

                       …

                       …

                 </MANIPULATION_PER_APPLICATION>

                 <HEADER_CHANGE>

                 …

                 …

                 …

                </HEADER_CHANGE>

        </MANIPULATION>

</APP_WRAP>

Important: Once you’re done modifying the AppWrap file, save it and then double-click it in order for it to open in Internet Explorer. If it opens without any errors, you can be sure that you did not break the XML file syntax while editing the file, and thus the file can be used by UAG. Otherwise, if the syntax is incorrect, IE will indicate that a problem exists and will usually give you a pretty good tip as to what is broken.

Conditional SAR

Conditional SAR (Search and Replace) is a new capability which enables performing manipulations only when certain conditions related to a UAG session parameter are met.

For example, we may want to remove the ‘Log off’ link from an application, but only when this application is published within the portal frame (where the portal ‘Log off’ button exists and should be used). We use the following SAR tag:
<SAR conditional_variable="UsePortalFrame" conditional_var_value="False">.

For example, hiding the ‘Log off’ button on SharePoint 2007:

<URL case_sensitive="false">.*\.aspx.*</URL>

         <SAR conditional_variable="UsePortalFrame" conditional_var_value="True">

                    <SEARCH encoding="base64">SignOut.aspx';" </SEARCH>

                    <REPLACE encoding="base64">SignOut.aspx';" style='visibility:hidden;'</REPLACE>

        </SAR>

</URL>

This option is also available for HTTP header manipulation.

Session parameters and their respective values can be obtained through the Session Details screen on the UAG Web Monitor.

Out of the box AppWrap main manipulations

Here is a list of the main kinds of manipulations performed by the AppWrap feature:

• Blocking uploads and downloads, according to endpoint policy definitions.
• Adding session timeout and logoff functionality to applications.
• Removing logoff functionality from applications published within portal.
• Fixing application publishing bugs (mismatch of HTTP & HTTPS, accessing wrong frames due to portal structure, etc.)
• Sending the Exchange CAS server the right HTTP request headers to support private/public access, as well as access to OWA Light.

Ron Gilad

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

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

It was a great TechEd in Berlin last week and a fabulous one for UAG. We got lots of positive feedback from you, our community. It is always a pleasure to meet so many of our users in one place and see the faces behind the names. I hope that those of you who attended our session got valuable information. For those who did not attend or could not get into the fully packed UAG session here are some additional videos:

1. UAG was demoed in Robert Wahbe’s keynote: http://www.msteched.com/online/view.aspx?tid=ba14667e-2879-4ff2-96d9-7bf63953f105 – Jump to 1:00:00.
2. UAG DirectAccess and beyond: recorded breakout session at http://www.msteched.com/online/view.aspx?tid=405de9ac-3334-4208-a828-681a35574446 – Requires TechEd Online subscription.
3. An interview and a demo on TechNet EDGE TV: http://edge.technet.com/Media/UAG-Demo-Screencast-and-PM-Interview/

See you in coming events,

Meir Mendelovich

Hi,

Tech·Ed Europe 2009 in Berlin is just around the corner!

For those attending the conference, there will be two UAG sessions, and a hands-on lab, as follows:

• Technical session SIA306 – Microsoft Forefront Unified Access Gateway: DirectAccess and Beyond, Tue 11/10, 10:45-12:00, Europa 1 - Hall 7-3b
• Technical session SIA04-IS – Microsoft Forefront Unified Access Gateway: More Secure Access for SharePoint and Microsoft Dynamics CRM from Virtually Anywhere, Thu 11/12, 13:30-14:45, Interactive Theatre 6 – Pink
• Hands-on lab SIA27-HOL – Unified Access Gateway (UAG) and Direct Access: Better Together

In these sessions we will unveil and explain the cool and powerfull new features of UAG 2010 along with detailed demos. We’ll also have a stand in the Security, Identity, and Access zone at the Technical Learning Center (TLC) . Come along to ask questions and get more information.

If you are members of the UAG community and will be attending Tech·Ed, please let us know that you are attending by sending us an e-mail with your contact details using this blog e-mail form.

Thanks! We look forward to seeing you

Meir Mendelovich on behalf of the UAG product group

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

Scenario
When attempting to install the e-Gap 3.6 version software, you might receive an insufficient disk space error even though there is plenty of hard drive space:

"There is not enough space on drive C:\ to extract this package. Please free up x MB and click Retry"

This situation is also applicable to other products. Information and a description of the cause can be viewed here: http://support.microsoft.com/kb/q189787/

Solution

When I encountered this error, I reduced the amount of free space on the hard disk to be slightly below a multiple of 4 GB. Also, you could increase the amount of free space on your hard disk to be at least 100 MB above a multiple of 4 GB. It is a good idea to start by clearing the %temp% directory.

Once this was done, I was able to run the e-Gap setup again with no issues.

Author

Renato Menezes
Security Support Engineer – IAG Team
Microsoft – North Carolina

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:

1. 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
2. 2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
3. 2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
4. 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

Secured messaging has just become easier with the recently announced RC0 version of Forefront UAG. Additional authentication methods are supported out of the box, simplifying the publishing process of back-end services, particularly Exchange mail.

Objective

Configure pre-authentication of Exchange mail applications, with no impact on the end-users, providing a seamless experience. Both the login process and the session itself are intact from an end-user perspective, having the extra layer of security with Exchange experience preserved.

Here is an illustration of the authentication entities:

[Figure 1. Authentication entities]

We will illustrate how to accomplish the objective using the following authentication matrix (this is merely an example as the authentication alternatives/combinations are much greater).

Outlook Web Access

The pre-authentication process is transparent to end-users, as they are being presented with a form-based login page (optionally identical to the OWA one), and using the client's approved credentials, standard basic authentication (HTTP 401) is used to authenticate with the Exchange Client Access Server (CAS).

You can configure this by creating a new Portal trunk, and selecting Publish Exchange applications, or by Adding an application to an existing trunk. When you reach the Authentication property page configure UAG to negotiate with the CAS by selecting 401 request. See Figure 2 below.

[Figure 2. Modify UAG back-end authentication method]

The above UAG configuration also requires you to configure the CAS to perform Basic authentication. From the Exchange Management Console, click on OWA properties, click the Authentication tab, and click Basic Authentication, See Figure 3 below.

[Figure 3. Modifying the CAS to accept Basic authentication for OWA]

To perform Form-Based Authentication using the OWA look & feel (instead of the UAG one), see Figure 4, select Configure on the published trunk, click the Authentication tab, and click Apply an Outlook Web Access Look and Feel.

[Figure 4. OWA Look & Feel]

Outlook Anywhere

Outlook clients provide a seamless authentication experience when configured to authenticate using NTLM. In this scenario, NTLM is the chosen authentication method between the client and UAG. Afterwards UAG requests a Kerberos ticket on behalf of the client. To enable Kerberos Constraint Delegation (KCD) in UAG, you need to modify the default authentication method for Outlook Anywhere. Select the Exchange application, click Edit and navigate to the Authentication property page, as shown in figure 5:

[Figure 5. Select KCD for Outlook Anywhere]

An extra level of authentication granularity is provided by allowing administrators to modify the authentication method of Exchange Web Services. These services play an important role in providing a rich experience for Outlook clients (they can also be used for building custom applications against Exchange).

Web Services are published by UAG automatically when publishing Outlook Anywhere. In figure 6 you can see the different Exchange applications, two of which were auto-published by UAG.

[Figure 6. Auto-published Exchange Web Services application]

This step in the Add applications wizard (when Outlook Anywhere is published) lets you selectthe authentication method for Exchange Web Services. It is recommended that select either Use Authentication Server (Basic using the repository defined in step 7, see Figure 2), or Use Kerberos Constrained Delegation. See figure 7. Selecting Do not Reply, instructs UAG to work in a pass-through mode against the back-end (for a full pass-through you will also need to eliminate the front-end authentication).

[Figure 7. Configuring Web Services Authentication]

ActiveSync

By default Basic authentication is deployed simply by selecting to publish Exchange ActiveSync. (See Figure 8. Publish Activesync)

[Figure 8. Publish ActiveSync]

Publishing Prerequisites

Things to consider before you begin publishing any of the above mail applications:

· The CAS certificate must reside on the Forefront UAG server.

· Kerberos Constraint Delegation requires that the Forefront UAG server and Exchange CAS are members of the same domain, and enabling delegation for the UAG server in the domain controller

· If Exchange is your only published application in a trunk, you may choose to have it marked as the initial application (see Initial application combo-box in Figure 4).

More information

We have updated the Exchange publishing guide using Forefront UAG.

Michel Biton

After working with the beta release for some time, you feel it’s time to move on… to RC0 :) The problem is you already have your whole environment up and running using the beta… what do you do? It’s pretty simple actually. With UAG RC0 you can migrate your server settings from UAG Beta 2. This is done with the new UAG Configuration Upgrade Utility that enables inter-release configuration migration. All you have to do is follow the simple instructions below and you will have your old environment up and running with an upgraded UAG server.

Step 1: Export

On your UAG Beta 2 machine, export the UAG configuration settings (choose File -> Export in the UAG Management console).

Figure 1: UAG Beta 2 configuration export

Step 2: UAG RC0 clean install

On the same server, or on a different server, perform a clean install of Windows Server 2008 R2 Standard or Enterprise (RTM release), and of UAG RC0. You’ll notice that we made some changes to make the installation process easier. There’s no need to run the prerequisite tool. All the required prerequisites are installed automatically when you run the UAG installer.

For more information on the setup process, please refer to the “Installing Forefront UAG software” TechNet article at http://technet.microsoft.com/en-us/library/dd857337.aspx.

Step 3: Upgrade process

On your UAG RC0 machine, go to “\Program Files\Microsoft Forefront Unified Access Gateway\common\bin”. Run the UAG Configuration Upgrade Utility (“UAGSchemaUpgradeUtil”) to complete the migration process. Provide the exported file name & path (from Step 1) and the export password. After validating the system pre-requisites and the exported file integrity, the upgrade utility performs the UAG configuration transformation into the RC0 schema format, and imports the configuration to complete the process.

Figure 2: UAG Configuration Upgrade Utility

Step 4: Post-migration

At this point, your UAG RC0 system is set up with your original UAG Beta2 settings! If the migration was between two different machines (or different sets of machines), make sure to update the node-specific settings, such as the IP settings of trunk definitions, IP ranges of IP-VPN settings (NC tunneling, SSTP), and machine certificates, with the new machine properties. Run Activate to complete the migration.

Migration of UAG array settings

The migration process from a UAG Beta 2 array to a UAG RC0 array is similar to that of a single node.

Step 1: On the AMS node of the UAG Beta 2 array, export the current array settings.

Step 2: Perform a clean install of Windows Server 2008 R2, and UAG RC0 on all array machines.

Step 3: Now you can either:

a. Build your new array and then run the upgrade utility on the AMS.

b. Or run the upgrade utility on one machine (AMS to be), then re-join the rest of the nodes to the new AMS.

Step 4:

a. Update the node-specific settings for the new machines.

b. In case of 3.b, re-define Windows NLB settings.

c. Activate to complete the migration (monitor the activation across the array nodes using Activation Monitor)

Now your array is rebuilt with the new UAG RC0 release bits and the existing configuration you built for UAG Beta 2.

For more information on the migration process, please refer to the “Importing migrated server settings” TechNet article at http://technet.microsoft.com/en-us/library/ee428835.aspx.

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!

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.

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

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

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