Microsoft Forefront Unified Access Gateway Product Team Blog

UAG is a Berliner – Meet Us in Tech·Ed Europe 2009

2009-10-29T20:44:00Z

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

Deep dive into UAG DirectAccess (Certificates)

2009-10-27T13:33:00Z

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

Insufficient Disk Space Error on e-Gap 3.6 version installation

2009-10-15T08:30:35Z

Technorati Tags: You Do Not Have Enough Disk Space to Install,insufficient disk space

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

Deep dive into UAG DirectAccess (IPv6 and DirectAccess)

2009-10-13T13:12:00Z

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

Authenticating Exchange Mail Applications using UAG RC0

2009-10-12T06:11:42Z

Technorati Tags: Authenticating Exchange,RC0,Exchange authentication,Authentication,Exchange

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).

Exchange mail application	Front-end Authentication	Back-end Authentication
Outlook Web Access	Form-based	Basic (401)
Outlook Anywhere and Web Services (excluding Autodiscover)	NTLM	KCD
Autodiscover Service	Basic	Basic
ActiveSync	Basic	Basic

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

Beta 2 Configuration Migration to RC0 - It’s Pretty Simple

2009-10-06T12:54:04Z

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.

Forefront UAG Release Candidate 0 (RC0) is here!

2009-09-25T21:00:00Z

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…

2009-09-22T19:34:00Z

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

2009-09-08T23:14:00Z

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

2009-08-27T15:23:00Z

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

2009-08-10T23:51:00Z

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

2009-08-02T21:41:00Z

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

2009-07-27T12:55:00Z

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

2009-07-20T21:28:00Z

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!

New White Paper: Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG)

2009-07-20T20:31:59Z

Even though we are focused on UAG these days, we and our partners still promote IAG and add more content for our community. Here is a blog cross-post from the CRM team blog on enabling ADFS for CRM using IAG. Most of the content of this paper is also true for UAG and for other applications like SharePoint.

By default, an on-premise implementation of Microsoft Dynamics CRM 4.0 leverages Active Directory (Integrated Windows) Authentication to accommodate access by internal users. However, many businesses also require the ability to provide external users with access to the highly sensitive information that is stored in the CRM system and to accommodate this access without having to create Active Directory trusts.

Because providing external access to internal CRM resources can also introduce potential security risks from both external and internal sources, in these scenarios, the CRM implementation must be protected by a gateway, such as Intelligent Application Gateway (IAG) 2007, which is sensitive to application logic and data and can ensure that internal and external users perform their routine tasks in a secure manner.

By using a combination of IAG and Active Directory Federation Services (ADFS) to establish an authentication gateway, companies can provide access to CRM resources by any identity, from any organization and from any computer, complete with strong authentication and full Single Sign On from the end user to the internal CRM system with a full audit trail (including username and source IP).

The white paper Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG), recently released by the MS CRM Engineering for Enterprise (E2) team, provides high-level guidance on using IAG to implement an ADFS solution for Microsoft Dynamics CRM 4.0. Developed in collaboration with the IAG team in Israel and the CRM Product team in Redmond, the document is available on Microsoft Downloads at:
https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=47ee7f73-6059-4b20-a305-1b8b2b23f0e9

Cheers,

Jim Toland

CRM Engineering For Enterprise