I was recently approached by one of our customers, in search for information about the "Bind the source IP to the session" setting which appears on the Session tab of the Advanced Trunk Configuration window.

What does it not do?

In order to avoid possible confusion, let's begin by stating what this option does not do: it does not create any binding or association between a client's source IP address (as it appears in TCP packets sent from the client machine to UAG), and the UAG session. As a matter of fact, this feature has nothing to do with the "external" side of the UAG, meaning with the traffic between UAG and its clients.

So what is "Bind the source IP address to the session" used for?

As you are probably very well aware, as a reverse-proxy UAG splits connectivity between clients and backend servers into two separate connections - the TCP connection between a client and the UAG server; and the TCP connection between the UAG server and the backend application servers. The "Bind the source IP to the session" option affects only the internal side of a UAG server, meaning the TCP connection established by UAG to backend Web applications published through UAG. Note that this setting applies only to HTTP/S traffic sent from UAG to Web applications. It is not applicable for any other protocol (tunneled or otherwise) sent through and by UAG.

You enable the "Bind the source IP address to the session" setting to specify which specific IP address UAG should use as the source IP address for each specific session, when creating a new TCP connection to one of the backend Web application servers. The IP address should be one of the addresses defined on the internal NIC of the UAG server. If this setting is not enabled, all TCP connections will have the same source IP address, which is the primary IP address defined for the UAG internal adapter.

How do I configure this setting?

Configuration is a combination of two settings, which can be applied in any order:

1. Obviously, you need to enable the setting in the UAG Management console, and activate the configuration

2. You need to create a UAG hook file which contains a piece of VBScript that specifies (according to whatever logic you wish to implement), which IP address should be used for that specific UAG session. This file is invoked, and the VBScript executed, once per each session, during the session authentication process. The file should be placed in the .\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate folder, with the following naming convention: [Trunk Name][0 for HTTP trunk or 1 for HTTPS trunk]PostPostValidate.inc . For example, if you want to use this feature on an HTTPS trunk named Contoso, the file name should be Contoso1PostPostValidate.inc .

A sample script

The function that sets the source IP address to be used by UAG for TCP connections to backend Web applications, for the duration of the UAG session, is:

SetSessionParam g_cookie, "SessionSourceIP", "nnn.nnn.nnn.nnn"

Based on this, a very basic example of a script that specifies which source IP address should be used, based on user name, would look something like this:

A few troubleshooting tips

· Remember that this feature applies only to traffic between the UAG server and Web applications on the backend.

· Remember that the IP addresses specified in this script must be actual IP addresses defined on the internal NIC of the UAG server.

· If you enable the feature in the UAG Management console without creating the relevant script file, or using incorrect script syntax, or specifying an IP address that is not defined on the internal NIC, the following occurs:

o End users will receive an error page in their browser as follows: "You cannot access this site because a source IP address cannot be bound."

o The UAG Web Monitor displays one of the following errors:

§ Error ID 109: Failed to Get Session IP Address - The SessionSourceIP value cannot be retrieved. (This error usually indicates that your script is missing, or its syntax is incorrect)

§ Error ID 110: Session Source IP Address Invalid - The SessionSourceIP value cannot be used. The "<value specified in the script>" value is not a valid IP address.

§ Error ID 111: Failed to Bind SessionSourceIP - The SessionSourceIP value cannot be bound using the IP address <value specified in the script>. The error code is <error code> and the error message is <error message>.

Author

Ran Dolev | Senior CSS Engineer | Microsoft Unified Access Gateway Team

Reviewer

Rayne Wiselman | Forefront UAG User Assistance Team

I recently was engaged by a customer who was having issues publishing Citrix's XenApp applications, using the web server, via UAG. While we do have some information in the release notes (see Publishing and Authentication), this might be confusing for some and may not work without additional configuration for all versions of Citrix XenApp.

The Basics

Let's start with the basics. UAG can publish many things via many methods. For XenApp, it may be best suited to not reinvent what Citrix has already produced in their web application. They have a lot of infrastructure that can dynamically determine who what and how things should be displayed on the web page.

To have the best "better together" story, UAG can:

1. Provide a front end consistent portal landing page for logging into XenApp and other applications.

2. Provide SSO access to XenApp

3. Protect XenApp web server from external attacks

4. Reformat XenApp web pages for consistency (example, remove logout buttons)

How it works

To really show the experience, consider the following flowchart:

And the following architecture:

Seeing is believing

The following is a screens show a list of applications in the standard UAG portal, including XenApp.

After clicking the XenApp link the user automatically logs into the XenApp website. Notice the Application SSL VPN Tunneling Icon in the system tray .

And of course I can launch the published application (notepad) and we also see the Citrix Connection Center Icon in the system tray.

How to set this up

The setup is straight forward, provided by the wizard. In some more complex environment, this can be confusing. For that reason, we will walk through the 10 step wizard plus enabling the SSL Application Tunneling for XenApp, which is discussed in the release notes (Publishing and Authentication).

Step 0: Log into an existing installation of UAG and access the Management Console.

Step 1: Select an existing trunk and click the Add button in the application list on the right. Select Brower-embedded --> Citrix XenApp (Web Interface 5.0).

Step 2: Name the Application.

Step 3: Select any special Endpoint Policies (I just left mine as default and you can change them later).

Step 4: Select configure an application server.

Step 5: Type in the hostname of your Citrix XenApp Web Server. This can be a single server, a set of servers or a set of servers behind a load balancer.

Step 6: Select you Authentication Servers.

Step 7: Define all Citrix XenApp Servers in the Farm(s) that you publish or you can use regex (regular expression) to express servers with a similar naming standard. In my case, all Citrix servers start with "SCD-CI-XA", so I can use "SCD-CI-XA*". More info on RegEx used in UAG at: http://technet.microsoft.com/en-us/library/dd282903.aspx.

Step 8: Define how you want the portal link to appear. "Open in a new window" is the default. I personally prefer not to use a new window when possible. UAG can do both!

Step 9: Select any user or groups that you want to restrict this to

Step 10: Complete the wizard, save the changes and Active the configuration

Step 11: Because UAG does not automatically enable SSL Application Tunneling for Citrix by default, you need to enable this via a configuration file. Per the release notes (Publishing and Authentication), add the following content to the "%Program Files%\Microsoft Forefront Unified Access Gateway\von\Conf\SSLVPNTemplates.xml" file.

<!--

*********************************************************************************

** Citrix Presentation Server (Web Interface 3) **

*********************************************************************************

-->

<!-- Auto-Sense mode -->

<template name="CitrixPresentationServer" wfehandler="yes" userrights="0" use-with-lsp="yes" default="yes"><!--All platforms-->

<port id="0" remoteport="1494,2598" flags="73" default="yes"/><!--All Platforms--> </template>

As shown below:

At this point, once UAG, TMG (Threat Management Gateway, a supporting technology in UAG) and IIS have updated their cache, users will be able to see the published application. In lab or test environments, I restart IIS to force the changes now.

I am getting an "Application "xxx" cannot be launched." error

You will get this error if you have not completed step 11 above. Verify the syntax and placement of the file. Also perform an IIS reset after making the change.

Application "%Your Application Name Here%" cannot be launched. The application is not listed in the "Applications" list on the server.

Please contact you system administrator for more information.

Actual error message is shown below.

I am getting a "Session Error" with XenApp web server

Depending on your version of Citrix XenApp web server, you may get the following error:

Session Error

There is a problem with your session. For security reasons, you must close your browser window and log on again to continue accessing your published resources.

To logon again, you must restart your browser.

Actual error message is shown below.

This error can be resolved by adding the following content to the file "C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\Websites\<your trunk name>\conf\CustomUpdate\WhlFiltAppWrap_HTTPS.xml" which will rewrite the XenApp HTML to avoid the error. More info about what the change is actually doing later.

<MANIPULATION_PER_APPLICATION>

  <APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE>

  <!-- citrix 4.5 fix client cookies issue -->

    <DATA_CHANGE ee="1">

    <URL case_sensitive="false">/Citrix/.*/auth/login.aspx</URL>

    <!-- check if RWS is secured or not -->

    <SAR>

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

      <REPLACE encoding="base64">d2hsSXNTZWN1cmUgPSAiRkFMU0UiOw0KZnVuY3Rpb24gY2hlY2tXSExSV1MoKQ0Kew0KIHZhciB3aGxVUkwgPSBsb2NhdGlvbi5ocmVmOw0KCSBpbmRleDEgPSB3aGxVUkwuaW5kZXhPZigiLy8iKTsNCiAgICAgICAgICAgICBpbmRleDIgPSB3aGxVUkwuaW5kZXhPZigiLyIsaW5kZXgxKzIpOw0KICAgICAgICAgICAgIGluZGV4MyA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDIrMSk7ICAgICAgDQoJIGluZGV4NCA9IHdobFVSTC5pbmRleE9mKCIvIixpbmRleDMrMSk7ICAgIA0KICAgICAgICAgICAgLy9nZXQgdGhlIHdobCBpbmRpY2F0b3IgZm9yIGEgc2VjdXJlLyBub24gc2VjdXJlIFJXUyAgICAgICAgICAgICAgICANCgkJd2hsVVJMID0gd2hsVVJMLnN1YnN0cmluZyhpbmRleDQtMSxpbmRleDQpOw0KCQkvL21lYW5zIHRoZSBSV1MgaXMgc2VjdXJlZA0KCQlpZiAod2hsVVJMID09ICIxIil3aGxJc1NlY3VyZSA9ICJUUlVFIjsNCn0NCmNoZWNrV0hMUldTKCk7ICAgICAgICAgICAgICAgIA0KZnVuY3Rpb24gc2V0SXRlbUluQ29va2llKG5hbWUsIHZhbHVlKQ==</REPLACE>

    </SAR>

    <!-- setting isSecure to false -->

    <SAR>

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

      <REPLACE encoding="base64">dmFyIGlzU2VjdXJlID0gd2hsSXNTZWN1cmU7</REPLACE>

    </SAR>

    <!-- remove secure setting when creating cookie on client machine -->

    <SAR>

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

      <REPLACE encoding="base64">aWYgKHdobElzU2VjdXJlPT0iVFJVRSIp</REPLACE>

    </SAR>

  </DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

Actual edited file shown below:

For those interested in what the above configuration is doing, UAG comes with a configuration file editor that allows you to convert base64 encoding to text. The conversion is shown and highlighted below:

How to remove the "Log Off, Reconnect and Disconnect" links

Now that XenApp is fully integrated from a protection, publishing and SSO experience with UAG, we move on to other less important topics. UAG provides a centralized authentication, logon, inactivity and logoff experience. XenApp also provides a "log off" option, one that can confuse users and break UAG's ability maintain log on / log off state. The screen below shows the "Log Off | Reconnect | Disconnect" links on the XenApp page. If a user clicks on the log off link, they will be back to the "Session Error" message listed above.

Our goal is to remove them, the exact same way that UAG removes the "Sign Out" link for SharePoint, see below (figure 1, SharePoint without UAG publishing, figure 2, SharePoint with UAG publishing):

Figure 1

Figure 2

To do this for XenApp, we need to set a few links to style="visibility:hidden;", which effectively hides the links. We also change the class from navLink to navLink_nopipe, so we also remove the "|" pipes that are associated with the links. The configuration for this, shown below, should be added to "C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\Websites\<your trunk name>\conf\CustomUpdate\WhlFiltAppWrap_HTTPS.xml":

<DATA_CHANGE>

  <!-- Removing log out disconnect and reconnect links -->

  <URL case_sensitive="false">/Citrix/.*/site/default.aspx.*</URL>

  <SAR>

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

    <REPLACE encoding="base64">aWQ9ImxvZ291dEFyZWFMb2dvdXRMaW5rIiBzdHlsZT0idmlzaWJpbGl0eTpoaWRkZW47Ig==</REPLACE>

  </SAR>

  <SAR>

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

    <REPLACE encoding="base64">aWQ9ImxvZ291dEFyZWFSZWNvbm5lY3RMaW5rIiBzdHlsZT0idmlzaWJpbGl0eTpoaWRkZW47Ig==</REPLACE>

  </SAR>

  <SAR>

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

    <REPLACE encoding="base64">aWQ9ImxvZ291dEFyZWFEaXNjb25uZWN0TGluayIgc3R5bGU9InZpc2liaWxpdHk6aGlkZGVuOyI=</REPLACE>

  </SAR>

  <SAR>

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

    <REPLACE encoding="base64">Y2xhc3M9Im5hdkxpbmtfbm9waXBlIg==</REPLACE>

  </SAR>

</DATA_CHANGE>

Which is placed in the <MANIPULATION_PER_APPLICATION> <APPLICATION_TYPE>CitrixXenApp5</APPLICATION_TYPE> section as discussed in "I am getting a "Session Error" with XenApp web server" above. Using the Configuration File Editor, we can see what the configuration is actually doing, shown below:

Once added and you restart IIS, the published XenApp page looks like:

For clarity sake, the final "C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\Websites\<your trunk name>\conf\CustomUpdate\WhlFiltAppWrap_HTTPS.xml" file looks like:

How was XenApp Setup

For this setup, XenApp version 5.0 was used. The configuration was as follows:

· Windows Server version: Windows Server 2008 x64

· Citrix Web Server Platform: IIS

· Citrix Web Interface Authentication: Explicit

· Citrix Web Interface Appearance: Full Graphics

Author:

Kevin Saye, Security Technical Specialist, Microsoft

Contributor:

Jason Jones, Forefront MVP, Silversands Limited

This post will discuss an issue that has cropped up a few times when clients try and access an SSL application on a backend server published through Forefront UAG.

The issue:

A client that is trying to access an SSL application on a backend server (e.g. Exchange) that is published through the Forefront UAG portal gets an error, specifically:

“An unknown error occurred while processing the certificate. Contact the site administrator”.

The cause:

This has nothing to do with the UAG certificates themselves but is most likely caused by an invalid certificate on the backend server. By default, Forefront UAG validates both the certificate and the revocation list of each SSL backend server during the TLS handshake procedure. In the event where the certificate or the CRL are not valid, users are denied access to that given backend server. This is also the case if the CRL distribution point is unavailable for any reason.

An easy way to identify if this is indeed the case is to open Internet Explorer on the Forefront UAG computer, and then try to access the backend server directly. If you get a certificate error at this stage, you have identified the problem as a certificate issue on the backend server.

The solution:

The best practice is to fix the certificate on the backend server, making sure to use a valid certificate. If you cannot (or don't want to) fix the certificate for some reason, another option is available: Disable the registry key(s) controlling the validation and/or the CRL checks that Forefront UAG performs.

Note that disabling the validation and/or the CRL check is not recommended (the validation check that Forefront UAG performs is there for a reason after all), but is offered as an alternative workaround to be used at your own discretion.

So, to disable the(se) checks in the Registry Editor:

1. Open the Registry Editor (Start –> Run –> Type “regedit” and click OK).
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\URLFilter\Comm\SSL.
3. To cancel the validation check, right-click ValidateRwsCert, select Modify, and change the Value data to 0.
4. To cancel the CRL check, right-click ValidateRwsCertCRL, select Modify, and change the Value data to 0.
5. Close the Registry Editor and then restart the IIS service on the Forefront UAG server.

Authors:
Meir Feinberg, Technical Writer, Forefront Edge
David Bahat, SDET, Forefront Edge

Over the past nine months, we have been working with early adopters of UAG DirectAccess as they discover, test, and deploy DirectAccess. One of the things that we are noticing more and more is that there are several aspects of DirectAccess that are not immediately obvious but that turn out to make a real difference to IT Pros and Information Security professionals. I thought I would describe some of these not-so-obvious aspects, and you will be able to see why they can be so attractive.

Normally, Information Security people view remote access technologies like VPNs as an annoyance – something that needs to be secured but without much security benefit. But DirectAccess can be different; although it will definitely be a little bit scary because there is a lot of technology that may be unfamiliar, it also offers a lot of additional potential to improve overall security. Here’s why:

DirectAccess is always on, and this means you can manage your roaming laptops whenever they connect to the internet, not just when their users decide to bring up a VPN connection

This is the whole “manage out” value of DirectAccess. There are two IPSec tunnels involved in DirectAccess. The first infrastructure tunnel is active right from when the lid of the laptop is lifted and an internet connection is available. It requires a computer certificate issued by you to be present on the laptop and the laptop must be a valid domain member of your Active Directory. This connectivity is narrow in scope and only allows connectivity to key infrastructure and management servers. The second, wider-scope tunnel opens once the user logs on. This requires the computer certificate, the user’s Kerberos logon, and optionally smartcard use or NAP health certificate. This intranet tunnel allows access to the data and resource servers on the intranet that a user may want to access.

So even before a user logs onto a laptop, the DirectAccess infrastructure tunnel springs into life and by default allows visibility of your internal DNS servers and some Active Directory domain controllers. You can also place additional management servers into this tunnel to suit your manage-out needs.

The early availability of this connectivity to internal resources means:

• Your computers can get GPOs right when they first boot, including things like computer startup scripts
• You can include your software distribution solution, like System Center Configuration Manager, into that first tunnel so the laptop can be patched and inventoried even when it is remote
• Your roaming laptops can pull patches from an internal Windows Software Update Services deployment, and can contact internal antivirus services for critical updates.
• Tools that reach out to the users’ computers, like vulnerability scanners, can get vastly improved chances of success in scanning roaming laptops

Activities that need users to be connected to the intranet work seamlessly: these will work even when the user does not know how to bring up a VPN connection

There are several activities that would work nicely if the user had brought up a VPN beforehand. These things will all work without any user procedures under DirectAccess. Examples of these types of activity are:

• Windows 7 and Office activation processes will be able to communicate with internal activation servers
• Bitlocker and Bitlocker-to-go key archival can work directly against Active Directory, so users’ Bitlocker keys can be safely stored away even when they trigger the encryption while they are remote

Password changes and resets can now work with roaming laptops

There are two common problems with password changes that really affect remote users.

The first is password resets for remote users. Users that forget their password or get locked out while remote will call the helpdesk, but if the user has no visibility of a Domain Controller, performing a password reset in Active Directory will not help the user unless he comes in and connects to the internal network. A user that cannot bring up a VPN because he cannot log in will not be able to use the VPN to get connected. But with DirectAccess, the user has visibility of a Domain Controller right from the CTRL-ALT-DEL prompt, so a password reset made by the helpdesk will be instantly visible to the end user. You should even be able to expose the Forefront Identity Manager self-service password reset portal through the DirectAccess infrastructure tunnel so that users can even reset their own passwords while roaming the internet.

The second is password changes by remote users. A roaming laptop user that changes a password in OWA will have this password change sent to Active Directory. But it will not affect the cached credentials on their laptop. The next time the user logs on, and tries to use his or her “new password”, the logon against the laptop cached credentials will fail unless the laptop is now attached directly to the intranet. With DirectAccess, a user can always change a password right from the CTRL-ALT-DEL prompt.

Additionally, computer account password changes, which happen every 30 days by default, would work correctly on a DirectAccess-enabled laptop, even for users that would almost never bring up their VPN. This can prevent legitimate computer accounts from being cleaned up by any AD cleanup activities that internal IT Pros may run.

Summary

If you think about all of the items above, you can see that always-on, seamless connectivity, available right from the CTRL-ALT-DEL prompt, can result in a more secure overall environment and can address several password handling scenarios that are not possible with a traditional VPN. Some of our customers are now deploying DirectAccess in a “manage-out-only” configuration where they are not even exposing the remote connectivity capabilities to their users – the manage-out capabilities are so powerful on their own, the other half of DirectAccess is not even needed to justify its deployment.

With DirectAccess, you will be able to answer the question, “how many of our laptops have received the antivirus update that covers ‘malware X’” with confidence, and you will not have to worry about your CIO forgetting her password while she is visiting Tuktoyaktuk.

Author:
Pat Telford, Principal Consultant, Microsoft

There are many underlying technology pieces that are used in a DirectAccess solution. These include IPv6, IPSec, the DNS Name Resolution Policy Table, UAG’s NAT64/DNS64, and a Network Location Service. Many or all of these are likely to be unfamiliar to you as you embark on learning about DirectAccess, and troubleshooting any problems in this environment can be daunting. This article should both help you understand the key individual components of DirectAccess and guide you through performing the troubleshooting steps that will narrow down the problem to a particular technology area.

The first things you should know are:

• Detailed Windows DirectAccess troubleshooting procedures are documented in the TechNet DirectAccess Troubleshooting Guide. There are some UAG DirectAccess specifics that are not included in this guide, such as how to troubleshoot NAT64 problems, but it is an excellent starting point for any DirectAccess problem.
• You can use the Network Diagnostics Framework in Windows 7 to troubleshoot DirectAccess issues and provide detailed tracing. NDF mixes together Windows events and actual traffic captures to provide a more unified picture of what is occurring when recreating a problem. An example is in this TechNet article.
• The DirectAccess Connectivity Assistant client utility, which is highly recommended as part of any DirectAccess deployment, has the ability to gather diagnostic output which can help you with troubleshooting.

But even before you dive into those options, you should take a look at the basic troubleshooting concepts shown in the troubleshooting one-pager below. This boils down UAG DirectAccess troubleshooting into a couple of initial pointers and then seven additional basic steps. Each step has some additional, more detailed follow-up items if the basic troubleshooting step fails.

The seven steps test out each of these technology pieces:

Step 1 – The Network Location Detection process and the DNS Name Resolution Policy Table

Step 2 – Basic IPv6 connectivity at the client

Step 3 – Traffic routing across the UAG DirectAccess Server

Step 4 – IPSec with certificates/NTLM authentication for the computer account, using a DNS query to the intranet

Step 5 – Authentication with an internal Domain Controller

Step 6 – IPsec with certificates/user Kerberos authentication

Step 7 – UAG’s NAT64 function to translate IPv6 traffic to IPv4 at the intranet edge

In step 2, you will verify that you have a usable IPv6 address. There are a number of possible types of IPv6 address when you include all of the IPv6-over-IPv4 transition technologies available to DirectAccess clients. You may find it useful to have the IPv6 addressing “cheat sheet” below with you when you start to work with IPv6, and especially when performing troubleshooting. It describes the main varieties of IPv6 addresses, and how they are composed – for example, you can see how a computer’s IPv4 address is often used as part of the IPv6 address.

These are the basic troubleshooting steps I always start with when examining problematic DirectAccess clients – I hope they help you too!

Author:
Pat Telford, Principal Consultant, Microsoft

A new feature of UAG 2010 is the publishing of a RemoteApp application on a single RDS server or by using an RDS connection broker. You can find the necessary steps to publish RemoteApps in the TechNet library at http://technet.microsoft.com/en-us/library/ee441339.aspx.

Although this step-by-step guide covers all basic configuration points, you have to consider some more important configuration settings in a real-world deployment with external and unmanaged clients.

1. RDS server certificate from a trusted public issuer

As soon as external and unmanaged clients access your portal and RemoteApps, you have to carefully examine the RDS server certificate. By default, a self-issued (self-signed) certificate is used. The recommendation from the RDS team is to use a public certificate (which means a certificate issued by one of the trusted public certification authorities). Please see http://technet.microsoft.com/en-us/library/cc770833.aspx for more information.

2. RDS server certificate from an internal PKI

However, if you plan to use a certificate from your internal PKI, you have to ensure that:

• Both AIA and CDP are accessible both internally and externally. To test if the AIA and CDP are accessible, you can use the following command:
  certutil –v –urlfetch -verify <RDSServer>.cer
• The certificate of the issuer is installed in the local computer’s trusted root certification authorities store (the user’s store doesn’t suffice, it must be the local computer’s store).

If you still have a problem getting the RemoteApps working because of problems with the CRL, you can ignore revocation errors by modifying the appropriate registry key on a Windows 7 client:

• DWORD key: UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors
• Location: HKLM\\System\\CurrentControlSet\\Control\\LSA\\CredSSP
• Value: 1

3. Digitally signing RemoteApp applications

Another good idea is the digital signing of your RemoteApp applications, for example to help protect against manipulated .rdp files or to reduce the number of displayed confirmation dialogs (also called Web SSO). The digital signing process is described at http://technet.microsoft.com/en-us/library/cc754499.aspx. Digitally signed apps can be exported and imported in UAG like unsigned RemoteApps.

Author:
Dominik Zemp, Tech Solution Prof, Microsoft Switzerland

Reviewer:
Meir Feinberg, Technical Writer, Forefront Edge

Overview:

I have been asked on several occasions to compare and contrast ADFS with other Microsoft “Single Sign On” (SSO) technologies, such as Forefront UAG. While these are two very different architectures, they both can provide the same end-user experience, namely logging in once and accessing application after application. Not to go too deep into the comparison, here is the elevator pitch of the two technologies:

Active Directory Federation Services (ADFS)

• Requires agents to be incorporated into the web application – unless using Token agent.
• Requires connectivity to the host from the internet – this can be a direct connection or a connection via a reverse proxy / web publishing solution.
• ADLDS or Active Directory can be used as the account store.
• Open standards based and integrates with other Federation technologies.
• Licensing included in Windows CAL (Client Access License) or with the Windows Internet Connector.

Forefront Unified Access Gateway (UAG)

• Does not require an agent on the web server, as this is a gateway based solution.
• Can publish applications, eliminating the need to for an application server to have direct application connectivity with the internet.
• Can authenticate to many authentication repositories.
• Not based on open standards but it can be configured to pass credentials to other SSO and Federation technologies.
• Licensing included in Enterprise CAL (ECAL), or can be purchased standalone or as an Internet Connector.

The real goal of this blog is to discuss how to make ADFS version 1.1 and Forefront UAG work together and get the SSO benefits of both!

ADFS, one size architecture does not fit all:

Because of the flexibility of deployments in ADFS, there are many ways it can be deployed. Therefore, I will only address one deployment option in this blog, namely publishing the ADFS-A (also known as the Identity Provider – IdP) with an SSO experience with Forefront UAG (or IAG). It is important to note that this configuration is based on ADFS 1.1, which is part of Windows Server 2008 and Windows Server 2008 R2. This has not been tested or certified with ADFS 2.0.

Before we get too far into terms and acronyms, let me define a few here to level set everyone’s understanding:

Table 1

Consider the following typical (and generic) scenario (figure 1 below).

• The user’s web browser tries to access the web server and is redirected to the ADFS-R (proxy) server (steps 1 and 2) to authenticate the user.
• At the ADFS-R server, after discovery of what identity partner the user should access, the browser is redirected to the ADFS-A (steps 3 and 4).
• At the ADFS-A (proxy) server, they are authenticated and given an SAML token and redirected back to the ADFS-R server (steps 5 and 6).
• Once back at the ADFS-R server, the SAML token is exchanged for a token that the web server understands and the user is redirected back to the web server (steps 7 and 8).
• Finally, once the user’s web browser presents the appropriate token (cookie), the web server allows the user access to the content (steps 9 and 10).

Figure 1

This may look like a lot of redirections but remember that once this is setup it happens in mere seconds or milliseconds, so the user does not see the complexity required to facilitate federation.

With Forefront UAG, we can replace the ADFS Proxy and provide a seamless secure user experience, eliminating redundant login prompts when used in conjunction with Forefront UAG. This architecture can be used with external federated partners or internal (inside your network) federated application servers. It is also worth mentioning that Forefront UAG can provide secure published access to the Application (Web Server), but that is not the focus of this blog (look here for other options on ADFS integration into Forefront UAG: http://technet.microsoft.com/en-us/library/dd857388.aspx).

It is not the goal of this document to go any deeper into the ADFS architecture or to discuss how to setup ADFS. Both of these are discussed on TechNet or on the internet using a Bing search (http://www.bing.com).

Why integrate Forefront UAG and ADFS?

If users are accessing application published by Forefront UAG and ADFS, without integration they will be asked for multiple logins. One of the great features of Forefront UAG or ADFS is the SSO, or single login experience. TechNet does a great job discussing each technology by itself, but this blog discusses how to make them work together and get the benefits of both. Assume the following:

1. A corporate user accesses a portal environment represented and protected by Forefront UAG.
2. Forefront UAG prompts the user for credentials and then provides the user access to the portal.
3. The user clicks a link that is protected by ADFS, either an internally or externally hosted server.
4. Without ADFS and Forefront UAG integration, the user will be prompted for the same credentials again and then allowed access to the web server.

With Forefront UAG and ADFS integration, users will not be prompted at step 4 for credentials. The following diagram shows this integration (figure 2).

In this scenario (figure2), we can see the SSO in action.

Consider the following Forefront UAG and ADFS integrated scenario (figure 2).

• The user accesses a portal published by Forefront UAG and is authenticated. The user then clicks on a link in the portal and is redirected to an externally hosted web server (steps 1 and 2).
• The user tries to access the web server and is redirected to the ADFS-R (proxy) server (steps 3 and 4).
• At the ADFS-R server, after discovery of what identity partner the user should access (home realm discovery), the user is redirected to the ADFS-A (steps 5 and 6).
• At the ADFS-A server (published by Forefront UAG), the user is automatically authenticated using the existing Forefront UAG cookie/credentials and given a SAML token and is redirected back to the ADFS-R server (steps 7 and 8).
• Once back at the ADFS-R server, the SAML token is transformed into a token that the web server understands and the user is redirected back to the web server (steps 9 and 10).
• Finally, once the user presents the appropriate SAML token, the web server allows the user access to the content (steps 11 and 12).

Figure 2

This may look like a lot more redirections, but remember that once this is setup it happens in mere seconds or milliseconds and the user has a true “Single Sign On” experience.

Ok, I am sold, how do I get there?

Requirements:

The configuration is pretty simple. There are a few requirements:

1. You will need to define a dedicated IP address on the Forefront UAG server for publishing the ADFS trunk – you can’t share an existing Forefront UAG IP address.
2. You will need to configure an ADFS SSL (HTTPS) certificate on the Forefront UAG server. The SSL certificate must carry the FQDN of the ADFS server.
3. You will need to enable “cross-site single sign-on” authentication in Forefront UAG for the Forefront UAG Portal and the ADFS trunk, see: http://technet.microsoft.com/en-us/library/ee921441.aspx.
4. The cookie domain name of your ADFS trunk and the Forefront UAG Portal trunk should be the same, for example: the Forefront UAG Portal trunk could be named https://myportal.CONTOSO.COM and the ADFS trunk could be named https://adfs.CONTOSO.COM. As long as the domain names (CONTOSO.COM) are the same, you can use the Forefront UAG cross site authentication.

Setup (Publish ADFS with Forefront UAG):

The setup of Forefront UAG to publish ADFS is pretty straightforward. I will walk through it step by step here.

Step 1. Open up the Forefront UAG console, right click on HTTPS Connections, select New Trunk and then click Next.

Step 2. At the “Select Trunk Type” screen, select ADFS trunk.

Step 3. Click Next at the “Select Application” screen.

Step 4. At the “Setting the Trunk” screen, name the trunk (any valid name will work) and type in the external DNS name that you publish your ADFS server. Select an unused external IP address for the published ADFS site. Remember this IP address is dedicated to the ADFS trunk.

Step 5. At the “Authentication” screen, select the AD server you have defined for use by your existing Forefront UAG trunks.

Step 6. At the “Certificate” screen, select a valid SSL cert that includes the FQDN of the ADFS server name you typed in step 4. In my example, I use a wildcard certificate. Note, this does not have to be the same certificate or the token signing certificate that ADFS uses, it simply has to be valid for the name in step 4.

Step 7. At the “Application Server” screen, type in the internal IP address of the ADFS server, select the port as 443, check the “Use SSL” box and type the valid internal DNS name of the ADFS server. In my case, the internal name is quite different from the external name, but because I use wildcard certs on both Forefront UAG and the ADFS server, the internal server name and the public host name of the trunk (see step 3 of the wizard) do not need to be the same. WARNING: If your ADFS server also hosts your web application, you will want to use a different name, so that Forefront UAG does not rewrite content it should not. Generally, it is recommended to use specific certificates instead of wildcard certificates.

Step 8. At the “Application Login” screen, select the same AD authentication server you selected in step 5 above. Note that it only uses 401 requests (ADFS calls them Windows Integrated logon pages) and it will not use HTML forms authentication by default.

Step 9. At the “Endpoint Security” screen, accept the default and click Next (Endpoint security will be disabled by default later).

Step 10. At the “Endpoint Policies” screen, accept the default and click Next.

Step 11. At the “Completing the Create Trunk Wizard” screen click Finish.

Step 12. Activate the configuration and perform an IIS reset. Optionally, you can click the Configure button under the Trunk Configuration area to view and modify any settings. Pay attention to the “Server Name Translation” tab (not shown) and the “Session” tab. Notice the Session tab has “Disable component installation and activation” checked by default. The key difference with the ADFS Proxy trunk setup as described on TechNet is that we use authentication on this trunk and use these user credentials to authenticate to the ADFS server to get a SAML token.

Testing (Publish ADFS with Forefront UAG):

Now that it’s setup, time to test. Make sure that the ADFS protected resource (web server) that you are typing into the address field refers to the hostname you typed in step 4. Assuming this is the case, when you try access the web site, you will be redirected to the Forefront UAG login screen (see figure 3 below).

Figure 3

After logging in to the Forefront UAG portal, you will be redirected to the appropriate ADFS protected resource.

Setup (Enable Cross Site Authentication):

Cross Site Authentication is the configuration option that allows you to go from a Forefront UAG “Trunk” to “Trunk”, without having to authenticate at each trunk. This option is documented at: http://technet.microsoft.com/en-us/library/ee921441.aspx, so I won’t rewrite this, but instead just refer to it. In my case, I had to modify the following files which are all discussed in the link:

• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\adfssso.inc (see figure 4)
• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\uagsso.inc (see figure 4)
• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\adfs\conf\CustomUpdate\WFEList.xml (see figure 5)
• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\uag\conf\CustomUpdate\WFEList.xml (see figure 5)
• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\adfs\conf\CustomUpdate\WhlFiltSSO.ini (see figure 6)
• C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\uag\conf\CustomUpdate\WhlFiltSSO.ini (see figure 6)

Figure 4

Figure 5

Figure 6

Testing:

Demonstrating this is quite simple. In my lab environment, I simply open my browser to my ADFS protected web site, and get redirected to https://sso.scd-labs.com, which is my ADFS Server published via Forefront UAG. After authenticating once, I am sent back to my ADFS protected website. Next, to prove that the ADFS to Forefront UAG integration works, I just type in the Forefront UAG portal in the web browser and I am automatically logged in without being asked for credentials. I can also go the other way, meaning log into Forefront UAG first, then redirect from Forefront UAG over to the ADFS web site and access the site without being prompted for credentials.

Summary:

So assuming your testing went well, we have integrated ADFS and Forefront UAG, gaining the unique strengths of both solutions and only asking the user to log in once. You will also notice that once you log out of either the Forefront UAG or the SSO site, you are logged out of both because the session cookie in the user’s browser is destroyed.

Author:
Kevin Saye, Security Technical Specialist – Microsoft

Reviewers:
Ben Ben Ari, Senior Support Engineer – Microsoft
Carsten B. Kinder, Principal Consultant – Microsoft
Eddie Huibers, Consultant – Microsoft
Mike Havens, Senior Support Engineer – Microsoft
Meir Feinberg, Technical Writer – Microsoft
Mohamed Mall, Security Technical Specialist – Professional Advantage

I am happy to announce the availability of Forefront Unified Access Gateway 2010, Update 1.

UAG Update 1 can be downloaded from Microsoft Download Center, here. In addition, UAG Update 1 is also available via the Microsoft Update channel.

The accompanying KB article (KB981323) details the contents of the release, is not available at this stage and will be available at following this release.

UAG Update 1 includes many bug fixes. It also includes the following enhancements:

• Remote Desktop access from Windows Vista and Windows XP: Client endpoints running Windows Vista and Windows XP can now access RemoteApps and Remote Desktops published through Forefront UAG.
• Support for Microsoft Office Forms Based Authentication (MSOFBA): Forefront UAG now supports the Office Forms Based Authentication protocol to allow rich clients to directly access applications published through Forefront UAG.
• Support for site cookies: Forefront UAG now supports the use of site cookies for non-alternate access mapping applications, in addition to domain cookies.
• Support for large CustomUpdate files: Forefront UAG now supports CustomUpdate files up to 1.5 GB in size.
• Support for SharePoint 2010
• Changes in Group Policy Object (GPO) provisioning for DirectAccess clients: Update 1 fixes an issue that caused the export script   that creates GPO objects to fail, and an issue that caused the GPO to be applied to all authenticated users in the domain (including computer accounts), instead of to DirectAccess clients only.  

Best regards on behalf of the entire UAG product team. Thanks in advance for helping us improve UAG for a better user experience, and thanks for spreading the word.

Yossi Yossifon

First of all I’m glad to meet you on the UAG Team blog. My name is Alexey Goldbergs, I’m a Technology Solutions Professional on Security from Microsoft Russia, and I’m going to share with you my experience on SAP NetWeaver Portal publishing through Forefront UAG with single sign-on.

You probably know that IAG 2007 has a special wizard for publishing SAP Enterprise Portal 6. The UAG product team decided to drop special wizards and develop a unified publishing wizard instead.

But before we get started let’s imagine that we have SAP NetWeaver Portal with an internal FQDN http://sapportal.contoso.local.

Publishing

1. On the first step in the application wizard you can choose a Web application template. For SAP NetWeaver Portal publishing (in my case that was v.7), I’ve used the “Other Web Application (portal hostname)” template, but you can also use “Other Web Application (application specific hostname)”. (You can find more details on this template’s benefits on Rayne Wiselman‘s blog post). It doesn’t really matter in this case
2. The second step is setting the name and type of your application. This is the place for creative thinking :) You can specify any application name and almost any application type, for example:
   · Application name: Intranet
   · Application type: SAPPortal
3. On the Endpoint Security page, select the endpoint policies for your application.
4. On the fourth step specify whether you want to publish a single server or a Web farm.
5. On the Web Servers page, if you are publishing a Web application, configure settings for the backend Web server that you want to publish. As I've mentioned earlier in my blog, my backend Web server is http://sapportal.contoso.local. In most cases the HTTP port for the SAP NetWeaver Portal is 50000 and you should set it as “HTTP ports” value.
6. On the Authentication page you should specify how clients provide credentials to published backend Web servers that require authentication but at this time we keep it clear and will come back to it later.
7. On the Portal Link page, step 7, you could specify how the application appears in the portal home page of the trunk, and you should set the SAP NetWeaver Portal home page as the “Application URL”. 
   Note: Check “Open in new windows” checkbox. This is because some applications are not “frame friendly” and SAP NetWeaver Portal is one of them.
8. The Authorization page is the last page before you get finished and there you can select users or user groups who will have access to this application.

Now you have finished the application publishing!

Note: Include UAG Portal URL to Compatibility View Settings in IE8 at the endpoint. SAP Portal doesn’t work correctly on IE8 with default settings. You’ll find more details on this issue at SAP Note 1296463 (authentication required).

Single Sign-On

Before IAG 2007 SP2, single sign-on with Kerberos authentication was a hard job. You can find how it was done at Jan's blog post. But starting from SP2 it became much easier with Kerberos Constrained Delegation (thanks to Eli Tovbeyn who was the PM for this feature).

For configuring SSO for SAP Portal you should have SPN for SAP NetWeaver Portal service. In my case SAP Portal was started in the context of service account j2ee@contoso.local with SPN HTTP/intranet.contoso.local.

Now is the time to return to Authentication page.

Here you’ll find step-by-step guide on configuring KCD for application using your SPN.

Note: SPN is case sensitive.

After you have completed all of the tasks you should activate the UAG configuration.

Issue

When you’ll try to get access to SAP Portal from UAG Portal you could see the following page:

What’s the problem?

As you might know, the SPNego solution used by the SAP NetWeaver Portal v.7 is based on Java 1.4.2. Unfortunately Java 1.4.2 only supports the DES Encryption type for Kerberos.

With Windows 7 and Windows 2008 R2, Microsoft decided to stop supporting DES Kerberos encryption by default. This is all documented at KB 977321.

Solution

1. In order to get SPNego working again we have to enable DES_CBC_MD5 encryption.
2. Start GPEDIT.msc on the UAG host.
3. Go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
4. Double click on "Network security: Configure encryption types allowed for Kerberos" and select (at least) the entry DES_CBC_MD5 which from now on allows Kerberos tokens that are encrypted with DES_CBC_MD5. (In order to prevent issues with other applications you might want to consider enabling all other encryption types as well, or at least the ones that were active by default before).

And now you can get access to you SAP NetWeaver Portal from anywhere, any device and any time!

Take care and see u next time!

Author:
Alexey Goldbergs, Technology Solutions Professional, Microsoft Russia

Reviewers:
Ophir Polotsky, Supportability Program Manager, Forefront Edge
Simon Rabinowitz, Technical Writer, Forefront Edge

Today I want to talk about how to configure the UAG DirectAccess server security policy to enable certificate enrollment from the Certificates MMC console.

By default, when you try to use the Certificates MMC console for certificate enrollment from the UAG DirectAccess server you will see the RPC server is unavailable message, as seen in figure 1.

Figure 1

This is due to the default security policy on the UAG machine.

To help you solve this problem, I’d like to shed some light about the networking protocols that are initiated behind the scenes when you try to request a certificate using the Certificates MMC console and how you can enable these protocols in the Forefront UAG server security policy so that you can successfully request certificates using the Certificates MMC.

The Networking Protocols used by the Certificates MMC for Certificate Enrollment

When you run the Certificate Enrollment wizard, in most cases you will try to connect to the Active Directory Enrollment Policy. That policy exists in Active Directory, and requires LDAP connectivity from the UAG DirectAccess server to your domain controllers.

After the Wizard connects to the Active Directory, it retrieves the different elements associated with Certificate Enrollment process, including a list of Certificate Authorities, and the templates list used by the Certificate Authorities. Then, after the wizard has this information it will ask you to answer a few questions about the characteristics of the certificate you want to enroll. At the end of the wizard the certificate request is created on the client and sent to the CA. The important thing to note here is that communication between the client and the CA is done using DCOM, and requires DCOM connectivity between the client and the CA.

Networking Policy Changes Required on the Forefront UAG Server to Make the Certificate Request

To enable DCOM and LDAP to the CA and domain controllers, you need to configure Forefront UAG security policy to enable LDAP traffic from the Forefront UAG server to the domain controllers, and DCOM traffic from the Forefront UAG server to the CAs.

Fortunately, the default security policy already allows LDAP connectivity from the Forefront UAG server to the domain controllers. This leaves us with the task of enabling DCOM traffic between the Forefront UAG server and the CA.

DCOM traffic starts by using TCP port 135, which is the RPC endpoint mapper’s port. Later it switches to a different TCP port based on negotiations that took place after connecting to the endpoint mapper. The port number it switches to is given to the DCOM client (the Certificates MMC in this example) during the initial conversation on TCP port 135. This conversation is encrypted by default. Since the traffic is encrypted, we can’t tell in advance what port will be used to enable traffic from the Forefront UAG server to the CA.

Another important point is that by default the Forefront UAG server looks into all conversations on TCP port 135 and when it sees encrypted traffic it blocks the communication altogether (before the two sides have a chance to negotiate the port that would be subsequently used).

Therefore, what we need to do is:

• Enable all traffic from the Forefront UAG Server to the CA
• Tell the Forefront UAG server not to terminate encrypted communications between the Forefront UAG server and the CA on TCP port 135

Enabling Certificate Enrollment from the TMG console on the Forefront UAG Server – Step by Step

The Forefront UAG server includes Forefront TMG server technology. TMG acts as a firewall for the UAG machine. What we want to do is open the TMG management console and enable DCOM traffic and encrypted conversations on TCP port 135.

Important note In general, we recommend that you do not change the TMG configuration (customize TMG firewall rules, create new firewall rules) from within the TMG management console. The exceptions are when you use documented procedures such as this one. The reason for this is that UAG behavior relies on certain elements configured in TMG, and changing them might make Forefront UAG server act in an unpredictable way.

Step 1:

The first thing you need to do is open the TMG management console by starting the Forefront TMG Management application.

Figure 2

Step 2:

Next, left click on the Firewall Policy node and view the list of existing Firewall rules. Then, left click on the first rule named Publishing Rule::Anchor::Begin

  Figure 3

Step 3:

The next step is to create a new Access Rule. To do this, right click on the Firewall Policy node in the left pane of the console, point to New and click on Access Rule.

Figure 4

a. On the Welcome to the New Access Rule Wizard page, name the rule Allow all protocols from localhost to CA.

Figure 5

b. On the Rule Action page, configure the rule as an Allow rule.

Figure 6

c. On the Protocols page, configure the rule to allow All outbound traffic.

Figure 7

d. On the Access Rule Sources page, set the source Network as the Local Host Network.

Figure 8

e. On the Access Rule Destination page, create a new Computer Object for your CA and set that CA as the destination for the Access Rule. The Computer Object should contain the IP address of the CA.If there is more than one CA you should create multiple Computer Objects with different IP address and add all of them.

Figure 9

f. On the User Sets page, accept the default, which is All Users.

Figure 10

Step 4:

Next thing you need to do is enable encrypted traffic on TCP port 135. To do that you need to open the System Policy Rules. Right click on Firewall Policy in the left pane of the console, point to All Tasks and click Edit System Policy.

Figure 11

a. On the left side of the System Policy Editor, navigate to the Authentication Services Configuration Group and click on Active Directory.

b. On the General tab, remove the checkmark from the Enforce strict RPC compliance checkbox.

Figure 12

Step 5:

Click the Apply button to save the changes to the TMG configuration. We recommend that you export the configuration before applying the changes

Figure 13

After the changes are applied, it should take only a few moments for the Forefront UAG server to apply the new configuration. Once the new settings are applied you should have no problems requesting or renewing certificates from the Forefront UAG server.

That’s about it for today!

Thanks -

Author:
Ben Bernstein, Senior Program Manager, Forefront Edge

Reviewer:
Tom Shinder, Technical Writer, Forefront Edge

Hello there! My name is Daniele Francioni and I work as an IT consultant in Microsoft Italy.

As you know, DNS is a core element in many kinds of IT infrastructures, from Active Directory to IPv6 networks; however, in IPv6 networks, addresses are simply too long and too cryptic to remember and use. Dynamic DNS registrations do two things: (1) they allow clients to register their IP addresses in the corporate DNS to be easily reachable and (2) they play an important role in DirectAccess. A DirectAccess client frequently changes its IP address because it can connect from home, from a customer site, using a Mobile connection through 3G or HSDPA, and so on. Management servers rely on DNS to get the IPv6 address of remote DirectAccess clients, so dynamic DNS registration must work if you want to manage remote DirectAccess clients.

I’ve recently been involved in setting up a DirectAccess solution using Forefront UAG, and everything worked… except when a management server tried to contact a remote DirectAccess client. After a short troubleshooting session, it was found that remote DirectAccess clients were able to connect to the corporate intranet using DirectAccess, but they were not registering their IPv6 addresses in the internal DNS. Trying to force the registration with “ipconfig /registerdns” didn’t produce any errors in the event viewers, but also didn’t produce any records in the DNS.

The dial-up connection (in particular a mobile connection using a 3G modem) was the problem. When you create a dial-up connection, Windows does not enable “Register this connection’s addresses in DNS”.

When a client connects to the intranet through DirectAccess, it registers its IPv6 address only if the connection it’s using has that option checked. And, of course, the clients affected by the problem were using a dial-up connection with a 3G modem. Lesson learned: if you’re planning to deploy DirectAccess in your infrastructure and your mobile workforce extensively uses mobile cards (e.g. 3G or HSDPA cards), or dial-up connections, don’t forget to enable this option. If you do forget, the clients will be able to connect to your internal network, but you will not be able to manage them while they are at a remote site; a unique feature of DirectAccess.

If you use DirectAccess with Forefront UAG, DNS has one more important role. The NAT64 feature of UAG DirectAccess relies on DNS to allow remote DirectAccess clients to communicate with IPv4-only hosts. When a DirectAccess client tries to connect to a server, UAG intercepts the DNS query and splits it into two different queries: one looking for the AAAA record (IPv6 record) and the other one for the A record (standard IPv4 record). If DNS replies with either both records, or only the IPv6 record, the IPv6 address is returned to the DirectAccess client and no translation occurs since the client sends IPv6 packets directly to the requested server. If only the IPv4 record is present, UAG returns a specially crafted IPv6 address to the client (the last part of the address contains the IPv4 address of the server). NAT64 intercepts all IPv6 traffic directed to this address and translates it into IPv4 packets directed to the target server. This is particularly useful if you have server applications that are not able to communicate using IPv6. NAT64 only works when the connection starts from an IPv6 host, not vice versa. For this reason, if a server in your internal network needs to contact a remote DirectAccess client, it needs to be IPv6 enabled.

Suppose that you have two services installed on the same server: one service is IPv6 enabled and is used to manage clients, while the other one is not. For example, you installed SCOM 2007 on a Windows Server 2003 server with Remote Desktop Services (RDS) enabled. Many system services on Windows Server 2003 are able to only use IPv4 and RDS is no exception. You can install the IPv6 stack on Windows Server 2003 and let the SCOM service contact DirectAccess clients directly, but you won’t be able to connect to the Windows Server 2003 using RDS from a remote DirectAccess client. The problem is that no NAT64 translation takes place because there’s an IPv6 address registered in DNS; therefore, the client tries to connect using IPv6, but RDS on Windows Server 2003 is not able to receive IPv6 packets.

You can re-enable NAT64 translation by adding a second entry in DNS with the IPv4 address of the server and using it to connect to IPv4-only services. In this case, NAT64 translates all packets, and everything should work with no further issues.

Author:
Daniele Francioni, IT Consultant, Microsoft Services Italy

Reviewer:
James Kilner, Technical Writer, Forefront Edge

Summary:

I recently had a customer ask if they could send header values with Forefront Unified Access Gateway (UAG) to published web servers. While this is pretty simple once you know how to do it, I found there was little documentation on this topic, so I thought I would share this information in this blog. For this demonstration, I used the RTM version of UAG 2010 and a simple IIS server as the sample web server – any web server will do.

Author’s thought on security of Headers:

While UAG can be a replacement for a traditional agent based SSO solution, one should consider the security ramifications of depending on header values as a security control. Traditional “agent based” solutions, such as CA’s SiteMinder or Microsoft’s Active Directory Federation Services (ADFS) provide protection at the web server and they encrypt conversations from the authorizing store (policy / ADFS server) to the web agent. This simply means that the agents only trust the authorizing store, and they both encrypt the communication to verify the data in the communications. I have had some customers say “the vendor name here agent does not support the application, so we just send in a header value and the application then knows who the logged on user is”. This technically works, but ANY application, web page or web server can send a header value, so this is VERY insecure as a single security control. Most people augment this risk by restricting the web server to only accept HTTP/HTTPS connections from the proxy or gateway solution (UAG in this case). This is a risk mitigating approach, but is really susceptible to any device claiming to be that IP address or any administrator changing the configuration for personal gain. Something like IPSEC (between the UAG server and the webserver) is a better choice, but really depending on header variables for security is a bad choice. Header variables can help provide data to published applications, much like ADFS does with “Claims Aware” applications. If you want to securely depend on the authenticity of header values, please encrypt them with a unique key only shared between the web server and the UAG server. For my demonstration, I did not encrypt them, but adding encryption / decryption code is quite simple.

Configuration Process:

Step 1:

Create the file “..\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\uag1postpostvalidate.inc” where “uag” is the trunk name and 1 = secure (0 = insecure or HTTP). If your trunk name is “widget” and you are using a HTTPS site (everyone should be), the file name would be “..\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\widget1postpostvalidate.inc”. If the site were a HTTP the file name would be: “..\Microsoft Forefront Unified Access Gateway\von\InternalSite\inc\CustomUpdate\widget0postpostvalidate.inc”. Notice we add files to the “CustomeUpdate” directory. This is the only supported method, so please always work on files in the “CustomUpdate” directory.

See my example file below (figure 1) that performs a LDAP lookup to my Active Directory Domain named “SCD-LABS.NET” using the logged in user’s id and password to retrieve the displayname, mail and title. For a list of all “Session” variables that UAG exposes, see the appendix.

Figure 1 -- <trunkname>1postpostvalidate.inc

<%

If Session("repository1") = "SCD-LABS" then

   Dim oConn

   Dim rs

   Set oConn = Server.CreateObject("ADODB.Connection")

   oConn.Provider = "ADSDSOObject"

   oConn.Open "Ads Provider", Session("repository1") & "\" & Session("user_name1"), Session("password1")

   Set rs = oConn.Execute("<LDAP://dc=SCD-LABS,dc=net>;(&(objectClass=user)(sAMAccountName=" _

      & Session("user_name1") & "));displayname,mail,title;subtree")

   if not rs.eof then

      if rs.recordcount = 1 then

         SetSessionParamWithType g_cookie, "Hybrid_WhlStatusFlagX", trim(rs("displayname").value), "filter"

         SetSessionParamWithType g_cookie, "Hybrid_WhlStatusFlagY", trim(rs("title").value), "filter"

      end if

   else

         SetSessionParamWithType g_cookie, "Hybrid_WhlStatusFlagX", "ERROR: User Not found", "filter"

         SetSessionParamWithType g_cookie, "Hybrid_WhlStatusFlagY", "ERROR: User Not found", "filter"

   end if

   set oConn = nothing

   set rs = nothing

End if

%>

Step 2:

Modify your Application Wrapper File “..\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\uag\conf\CustomUpdate\WhlFiltAppWrap_HTTPS.XML” where uag = the trunk name. If my trunk name were widget, the file name would be “..\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\widget\conf\CustomUpdate\WhlFiltAppWrap_HTTPS.XML”. If you do not have a file in the CustomUpdate directory, copy the one from “..\Microsoft Forefront Unified Access Gateway\von\Conf\WebSites\widget\conf\WhlFiltAppWrap_HTTPS.XML” and make the following modifications shown below (figure 2). Always work on files in the “CustomUpdate” directory.

I added the content between the “<!-- Added header code here -->” sections. In human readable form, I have restricted my change to the Application Type “HeaderTest” and to any URL, as defined by the .* parameter, which is a regular express for * meaning all URLs. I could have used .*/Login.jsp.* which would indicate any path as long as the target file is login.jsp and with any following query string. Next I added 2 headers, MyHeaderX and MyHeaderY respectively. The actual value of this header is from a variable, defined by the using_variables=”true” parameter and then named the variables – which were defined in step 2. Why those names and how many variables can I use did you ask? UAG (former IAG, former eGap by Whale) defined these variables and out of the box provides 9 variables pre-defined that you can use. You can use Hybrid_WhlStatusFlagQ - Hybrid_WhlStatusFlagY. Other variables are already used.

Figure 2 -- Application Wrapper File

      <!-- Added header code here -->

      <APPLICATION>

      <APPLICATION_TYPE>HeaderTest</APPLICATION_TYPE>

         <URL>

         <URL_NAME>.*</URL_NAME>

         <ADD>

         <HEADER>

            <NAME>MyHeaderX</NAME>

            <VALUE encoding="" using_variables="true">Hybrid_WhlStatusFlagX</VALUE>

         </HEADER>

         <HEADER>

            <NAME>MyHeaderY</NAME>

            <VALUE encoding="" using_variables="true">Hybrid_WhlStatusFlagY</VALUE>

         </HEADER>

         </ADD>

         </URL>

      </APPLICATION>

      <!-- Added header code here -->

   </REQUEST>

</HEADER_CHANGE>

</MANIPULATION>

</APP_WRAP>

Step 3:

Perform an IIS Reset to apply the XML file changes.

Step 4:

Setup an application in UAG that matches the Application Type in step 2. I called my “Header Test” but the important match was the Application Type, which is “HeaderTest” (no spaces). After setting up the application, activate the changes.

Figure 3 -- Website setup in UAG

Step 5:

Browse the website published by UAG and view the headers with a simple header program. I include my simple program in the appendix. Notice that the values are real values from my Active Directory Store. Also notice that because these are request variable, the web server prepends “HTTP_” to the name. Also note, if you have made a mistake and did not set the values, the header variables, will assume the value TRUE.

Figure 4 -- Testing the change and see the headers

Appendix

Demonstration file default.asp:

<TABLE>

      <TR>

           <TD>

                <B>Server Varriable</B>

           </TD>

           <TD>

                <B>Value</B>

           </TD>

      </TR>

      <% For Each name In Request.ServerVariables %>

      <TR>

           <TD>

                <%= name %>

           </TD>

           <TD>

                <%= Request.ServerVariables(name) %>

           </TD>

      </TR>

      <% Next %>

</TABLE>

Important ASP Session Strings that UAG exposes:

There are 28 Session objects, but listed below are the more often used session objects that are strings (text values):

Author:

Kevin Saye - Security Technical Specialist, Microsoft

A customer presented the DirectAccess team with an interesting problem that brought together many pieces of how a DirectAccess works, and how things might not work in certain circumstances. Because the problem was an interesting one, and because it highlights how some features of DirectAccess work, we thought it might be a good idea to share our experiences.

The customer was using a UAG DirectAccess solution that included only the “manage out” capabilities. By “manage out” I mean that they’re currently only interested in the ability to manage the DirectAccess clients, regardless of where those DirectAccess clients are located. At this time they aren’t allowing their users to connect to the corpnet using what we call the “intranet tunnel”. While this isn’t a solution we’ve documented, it is possible to configure things to support a “manage out only” solution. For more information on the manage out (always managed) option, please see Deep dive into UAG DirectAccess (Tweaking the GPOs) at http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx

There were no problems with remote management of the DirectAccess clients and in fact they found this ability to keep remote clients in the same security state as on-network clients a fantastic advantage. In addition, they found that their “manage out only” solution enabled users to change this passwords using the same methods that on-network clients use – CTRL-ALT-DEL and click “Change Password”. If you’ve had to deal with password changes using a VPN or other solution, you’ll quickly appreciate just how nice it is that the users can change their passwords in the same why they always do, without having to fire up a VPN connection.

A Problem with Outlook or DirectAccess?

Prior to deploying DirectAccess, external Outlook users used RPC/HTTPS (Outlook Anywhere) to connect to Exchange when they were outside the internal network. When the users were on the internal network, they connected over MAPI/RPC. When the users connected from an external location using RPC/HTTPS, Outlook would ask the users for user name and password, but when on the internal network, Outlook did not ask. This is typical behavior and the solution was working well for them.

The problem seemed to come after they deployed DirectAccess. For some reason, Outlook users were being asked for their passwords when they were on the internal network. This wasn’t normal behavior for Outlook and led the customer to ask if the Outlook problem might be related to DirectAccess.

During the information gathering process it was discovered that:

• The customer had an IPv4 only internal network – there was no IPv6 connectivity available at all. Neither native IPv6 nor ISATAP was available.
• The customer’s current DNS infrastructure enabled users on the internal network to resolve the name that external users use to connect to the RPC/HTTPS proxy
• There was a path that enabled users on the internal network to connect over RPC/HTTPS to the RPC/HTTPS proxy.
• Internal could resolve the name of the IP-HTTPS listener and there was a path that allowed internal clients access to the IP-HTTPS listener on the external interface of the DirectAccess server.

Why is Outlook Asking for Credentials?

The answer to that question came quickly. The reason why the internal network users were being asked for passwords was that the Outlook client was no longer using MAPI/RPC to connect to the Exchange Server; it was using RPC/HTTPS.

What didn’t make sense about this is that the Outlook clients were configured to RPC/HTTPS if a slow link is detected. That is to say, the option On slow networks, connect using HTTP first, then connect using TCP/IP (figure 1) is selected. For some reason, the Outlook client detected that it was on a slow network.

Figure 1

At this point you might wonder why the RPC/HTTPS (Outlook Anywhere) connection was being established, even if the a slow link was detected, since in most cases, the name of the publicly accessible proxy used to publish RPC/HTTPS wouldn’t be available to hosts on the internal network. As it turns out, the name was resolvable to both internal and external clients and a path was available for the internal Outlook clients so that they could loop out through the Internet and back into the internal network to access Exchange. Not very efficient, but it did explain why the Outlook clients didn’t try to use MAPI/RPC.

But the team still couldn’t figure out why Outlook determined that there was a slow link between itself and the Exchange Server. There was no significant network congestion, so a fast link should have been detected and MAPI/RPC should have been used.

The Mystery of the Enabled IP-HTTPS Adapter

This got the team wondering if the DirectAccess client assumed it was on the Internet. That didn’t seem to be the case. When they ran

netsh namespace show effectivepolicy

it indicated that the DirectAccess client was on the internal network and that the Name Resolution Policy Table (NRPT) wasn’t being used to resolve names. The fact that clients appeared to have normal corporate connectivity (with the exception of the Outlook issue) confirmed that the DirectAccess clients didn’t think they were on the Internet.

However, the team did notice that the IP-HTTPS adapter on the DirectAccess clients was still active. That shouldn’t have been the case since DirectAccess clients use Corporate Connectivity detection to determine when to enable the IP-HTTPS adapter, and corporate connectivity should be successful.

The status of the IP-HTTPS adapter is a function of:

• Initialization of the IP-HTTPS adapter
• The results of Corporate Connectivity detection

IP-HTTPS Adapter Initialization

The IP-HTTPS adapter on the DirectAccess client initializes (also known as entering the Enabled state) if any of the following conditions are met:

• The DirectAccess client detects that it’s behind a Web proxy (note that web proxy detection is not automatic; the user must configure IP-HTTPS to use a specific web proxy)
• The DirectAccess client detects that it’s behind a port or protocol blocking firewall
• Policy requires that the IP-HTTPS link is always on (this is not configured by the UAG DirectAccess wizard)
• The user manually enables the IP-HTTPS adapter

Corporate Connectivity Status Detection

Corporate Connectivity detection is a little more complex. There are two possible states for Corporate Connectivity:

• Corporate Access
• No Corporate Access (default)

The DirectAccess client uses active and passive analyses to determine Corporate Connectivity.

There are two methods used for active probing:

• DNS probing. The DirectAccess client performs a DNS query to resolve an admin configured internal host name. This name is the Corporate DNS Probe Host Name. The Corporate DNS Probe Host Name is stored in the DirectAccess client Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DnsProbeHost
• Web probing. The DirectAccess client sends requests to an admin configured internal Web site. Any successful retrieval of a Web page is an indication of success. The Web probe URL is stored in the DirectAccess client’s Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\WebProbeUrl. The reason for the Web probe is that DirectAccess clients may be located behind a Web proxy server that performs DNS queries on the behalf of the DNS client. Since the DNS client service doesn’t perform DNS queries for the destination host name for Web proxy clients, this alternate method is required.

There are also two methods used for the passive probing:

• Path reachability monitoring. DirectAccess clients have a set of IPv6 prefixes of hosts on the corporate network. If any of the hosts are reachable, then Corporate Connectivity is confirmed. If all paths are unreachable, then Corporate Connectivity enters a Suspect state. If Corporate Connectivity remains in the Suspect state for three consecutive polls for an active connection to a host on the configured IPv6 prefixes, an active probe (either a DNS probe or a Web probe) is initiated to determine if Corporate Connectivity still exists. The list of acceptable prefixes is defined in the DirectAccess client’s Registry at HKLM\Software\Policies\Microsoft\Windows\ NetworkConnectivityStatusIndicator\CorporateConnectivity\SitePrefixes
• New IPsec Main Mode Security Association (SA) establishment. Corporate Connectivity can also be confirmed by the establishment of a new IPsec SA between the DirectAccess client and a destination with a corporate IPv6 prefix. Only Main Mode SAs are checked. Note that Main Mode SAs remain active as long as the interface is up. Therefore, Corporate Connectivity can only be determined by looking for the establishment of a new Main Mode SA. The DirectAccess client (NCSI) records the SA identification number (ID) of the last known SA for each interface. When a new interface with a larger ID is seen for an interface, Corporate Connectivity is confirmed. The list of corporate IPv6 prefixes for Main Mode SA establishment is stored on the DirectAccess client’s Registry at HKLM\Software\Policies\Microsoft\Windows\ NetworkConnectivityStatusIndicator\CorporateConnectivity\SitePrefixes

As you can see, passive reachability monitoring is performed continuously in the background. Also note that active probing takes place only after path reachability monitoring indicates Corporate Connectivity failure.

The Corporate DNS Probe Host Name is configured automatically by the UAG DirectAccess wizard and registered in DNS. This is registered in DNS as a quad-A (AAAA) record with the host name UAGDirectAccess-corpConnectivityHost and the IPv6 address ::1 (which is the local host address in IPv6). Note that the DirectAccess client only needs to resolve the name, not connect to the address mapping to the name, hence the reason why we use the local host address.

The UAG DirectAccess Wizard does not configure a URL for the Web probe active probe.

Determining the State of the DirectAccess Client IP-HTTPS Adapter

Whether or not the IP-HTTPS adapter is enabled depends on IP-HTTPS adapter initialization and the results of Corporate Connectivity detection:

• If the IP-HTTPS adapter is initialized, Corporate Connectivity is confirmed, and the DirectAccess client has an IPv6 enabled adapter other than the IP-HTTPS adapter, then the IP-HTTPS adapter deactivates.
• If the IP-HTTPS adapter is initialized, and Corporate Connectivity detection fails or there is no IPv6 enabled adapter other than the IP-HTTPS adapter, then the IP-HTTPS adapter remains active.

To understand how Corporate Connectivity for the DirectAccess client works, it helps to think about the adapters used by the DirectAccess client to connect to the DirectAccess server:

• 6to4 adapter. The 6to4 adapter is activated when the DirectAccess client is assigned a public IP address. (There are other requirements, but this is a key requirement).
• Teredo adapter. The Teredo adapter is activated when the DirectAccess client is behind a NAT device, but deactivates when domain location determination identify that the client is on the internal network and can communicate with a domain controller. (There are other requirements, but this is a key requirement).
• IP-HTTPS adapter. Used by the DirectAccess client when no Corporate Connectivity is detected.

What happens if the DirectAccess client tries to use 6to4 or Teredo to perform Corporate Connectivity detection? If the client is able to connect using either the 6to4 or Teredo adapter, and confirm Corporate Connectivity, the IP-HTTPS adapter is deactivated.

What happens if the DirectAccess client fails to confirm Corporate Connectivity using either the 6to4 or Teredo adapter? Then the IP-HTTPS adapter remains activated.

Note that IP-HTTPS activation may take place before Corporate Connectivity detection is complete. That explains why you will sometimes see both 6to4 and IP-HTTPS or Teredo and IP-HTTPS activated at the same time.

Putting Together the IP-HTTPS Pieces

Let’s summarize what we know so far:

• The customer is running an IPv4 only network (no native IPv6 and no ISATAP).
• The Outlook clients appear to be detecting a slow link between themselves and the Exchange Server.
• The 6to4 adapter doesn’t initialize because the clients are assigned private IP addresses.
• The Corporate Connectivity check is successful because the clients are able to resolve the Corporate DNS Probe Host Name that was automatically registered in DNS by the UAG DirectAccess Wizard.
• The Teredo adapter initialized, but then is disabled because Corporate Connectivity was confirmed because of the clients were able to successfully resolve the Corporate DNS Probe Host Name.
• The IP-HTTPS adapter is initialized and remains active because it doesn’t meet the requirements for deactivation (Corporate Connectivity was confirmed, but there are no other adapters other than the IP-HTTPS adapter that are IPv6 enabled).
• Network Location Detection is successful as demonstrated by the fact that the Name Resolution Policy Table (NRPT) is not being used.

Now it’s clear why the IP-HTTPS adapter was still active – the customer was running an IPv4 only network. In order to deactivate the IP-HTTPS adapter, we need to confirm Corporate Connectivity and have an adapter other than the IP-HTTPS adapter assigned an IPv6 address.

What’s with the Slow Link Detection?

Now that the team solved the IP-HTTPS problem, the next step was to determine if there was a relationship between the active IP-HTTPS adapter and Outlook’s slow link detection. Maybe the DirectAccess client on the internal network was using the DirectAccess IPsec infrastructure tunnel to connect to the DirectAccess server and “loop back” into the corpnet over the DirectAccess IPsec infrastructure tunnel connection – maybe that’s why there was a slow link detected?

This turned out to not be the case because in order to establish the DirectAccess IPsec infrastructure tunnel from the DirectAccess client on the corpnet and the external interface of the DirectAccess server, you would need:

• A path from the DirectAccess client on the corpnet to the external interface of the DirectAccess server. In our customer’s case, there was such as path, so we considered an IPsec tunnel between the Outlook client and the DirectAccess server’s external interface to be a possibility
• Windows Firewall with Advanced Security firewall rules to support the DirectAccess IPsec connection
• Windows Firewall with Advanced Security Connection Security Rules to support the DirectAccess IPsec connection

The second and third bullet points made it clear to the team that there was no traffic moving over a DirectAccess IPsec tunnel. The reason for this is that in order to establish the IPsec tunnels to the DirectAccess server, the DirectAccess client needs to enable either the Public or Private Profile in Windows Firewall with Advanced Security. When the Domain Profile is enabled, the firewall rules and Connection Security Rules required to establish the DirectAccess connection aren’t available – hence, even though the DirectAccess client could potentially connect to the IP-HTTPS listener on the DirectAccess server because there was an existing path, the IPsec tunnels could not be created – with the result that no data could move through the IP-HTTPS adapter.

The team confirmed that the Domain Profile was enabled on the DirectAccess clients on the internal network, which is consistent with the fact that the clients were able to connect to the Network Location Server and a domain controller. The reason why I say that this is consistent with being able to connect to the Network Location Server and a Domain Controller, is that these are these are the two requirements for activating the Domain Profile.

So, what was causing the slow link detection and causing the Outlook clients to use RPC/HTTPS instead of MAPI/RPC? From further investigations, it turned out that the IP-HTTPS adapter was reporting a link speed of around 100Kbps, slow enough for Outlook to decide that there is a slow link. At this point in time, we don’t have an answer for why Outlook decided to use this link speed value instead of the value provided by the NIC.

Summary

Let’s finish up with a summary of the technical issues that were encountered:

• The DirectAccess clients on the internal network were able to confirm Corporate Connectivity because they were able to resolve the Corporate DNS Probe Host Name.
• The 6to4 adapter is always enabled when the client has a public IP address. It is not enabled when the clients are assigned a private IP address, so the DirectAccess clients on the internal network had their 6to4 adapters disabled.
• The Teredo adapter initializes when the client is assigned a private IP address, but then is disabled because of a successful Corporate Connectivity check.
• ISATAP wasn’t being used on the network, so there was no ISATAP assigned IPv6 address.
• An IPv4 only host that has no IPv6 enabled interfaces other than the IP-HTTPS adapter will not disable the IP-HTTPS adapter because the client must be able to confirm Corporate Connectivity and have an IPv6 address on an adapter that is not the IP-HTTPS adapter before it disables the IP-HTTPS adapter.
• The IP-HTTPS adapter therefore remained active on the internal network DirectAccess clients.
• The IP-HTTPS adapter reported a slow link speed, which is then used by the Outlook client to determine that it is on a slow link, which caused it to use RPC/HTTPS preferentially – resulting in users getting authentication prompts.
• The NRPT is not in effect because Network Location Server detection was successful.
• DirectAccess IPsec tunnels were not established between the DirectAccess client and the DirectAccess server because the clients on the intranet were able to connect to domain controllers and the Network Location Servers on the intranet, and therefore the Windows Firewall with Advanced Security Domain Profile was active. DirectAccess clients must use the Private or Public Profile to enable the firewall rules and Connection Security Rules required to establish the DirectAccess client/server link.

Discussion

There were a few reasons why we decided to share these experiences with troubleshooting the Outlook problem this customer encountered after deploying DirectAccess. The problem was solved by changing their DNS configuration so that internal network clients were not able to resolve the name of the RPC/HTTPS proxy –which made the initially observed problem with users needing to enter credentials go away. However, we still haven’t figured out why Outlook was using the link speed reported by the IP-HTTPS adapter, so that’s not the reason why I wanted to tell this story.

Instead, in the process of trying to solve this problem, the team ended up with a better understanding how the IP-HTTPS adapter works, and how it’s treated as the “IPv6 adapter of last resort” for DirectAccess clients. It also helped the team understand the importance of Corporate Connectivity detection, how the IPv6 transition technology interfaces are activated and deactivated, as well as the importance of Network Location Awareness and how that controls the Profile used by Windows Firewall with Advanced Security.

While all the lessons learned were good and valuable, this scenario called out a potential issue we might have with IPv4 only networks. Since we now know that DirectAccess clients on IPv4 only networks will not disable their IP-HTTPS adapter, the result is always going to be that the IP-HTTPS adapter is always be enabled on machines configured as DirectAccess clients on these IPv4 only networks.

What are the implications of having the IP-HTTPS adapter always enabled? It depends on how the network is configured. The team saw with the customer discussed in this article that the result was no traffic could flow out the IP-HTTPS adapter because Network Location Awareness determined that the DirectAccess client was on the corporate network because connectivity to the Network Location Server and a domain controller could be established. Therefore, the Domain Profile was enabled in Windows Firewall with Advanced Security and no IPsec DirectAccess tunnels could be established.

But what if we had the following scenario:

• There is an IPv4 only network or the client is on a part of the intranet where there are no routable IPv6 addresses configured.
• Therefore the IP-HTTPS adapter will always be enabled on DirectAccess clients
• Also, suppose there is a failure to connect to the Network Location Server
• The failure to connect to the Network Location Server would result in a failure to detect that the client was on the corporate network
• The client then would be assigned either a Private or Public Network Profile in Windows Firewall with Advanced Security
• The client would also would continue to use the NRPT, due to the failure to connect to the Network Location Server – so name resolution requests for most or all internal network resources would be forwarded to the DNS proxy on the UAG DirectAccess server
• Private or Public Profiles enable the firewall rules and Connection Security Rules to enable DirectAccess IPsec tunnels to be established to the DirectAccess server
• The corporate firewalls block outbound access to UDP 3544 (used by Teredo), but allow anonymous outbound proxy access, or even non-proxied access to TCP port 443 on the external IP addresses assigned to the external interface of the UAG DirectAccess server
• The DirectAccess client establishes a DirectAccess connection to the UAG DirectAccess server and now is able to loop back into the corporate network by going out the corporate firewall and back into the network through the DirectAccess server. The response path would be the same path but in the opposite direction.
• All DirectAccess clients on the internal network will connect to internal network resources through the Internet connection used by the DirectAccess server, which would have significant performance impact for all internal network hosts that need Internet access, even though who are not configured as DirectAccess clients

While it appears that it would take an unholy confluence of events to enable the DirectAccess client on the internal network to actually loop back through the UAG DirectAccess server to reach internal network resources, it’s likely that you’ve seen similarly unlikely events take place in the past.

This brings up the question as to whether or not you should enable this kind of scenario on purpose. For example, it’s possible that your Network Location Servers might become unavailable at some point in time, even if you have configured them to be highly available. If you enable the scenario described above, your computers configured as DirectAccess clients will still be able to connect to internal network resources, even though it will be through a very inefficient link. If you don’t enable the above scenario, then the DirectAccess client will not be able to establish DirectAccess tunnels to the UAG DirectAccess server, the NRPT will still be active, and the DNS queries sent to the UAG DirectAccess server’s DNS proxy will fail. The end result is that the DirectAccess clients will not have network connectivity if they need to access a resource by name.

The answer to that question is based on what scenario you prefer. Would it be better to bring your Internet connection to its knees for the period of time it takes to get the Network Location Servers up again? Or would it be better to “brick” your DirectAccess client computers until you can get the Network Location Servers going again?

To help you plan for such an eventuality, you can use the blog post When Good Network Location Servers Go Bad – Preparing Against NLS Failure at http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx

FOR MORE INFORMATION:

Deep dive into UAG DirectAccess (Tweaking the GPOs) http://blogs.technet.com/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx

When Good Network Location Servers Go Bad – Preparing Against NLS Failure

http://blogs.technet.com/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx

Designing a DNS Infrastructure for Forefront UAG DirectAccess

http://technet.microsoft.com/en-us/library/ee428856.aspx

Designing Your Intranet for Corporate Connectivity Detection

http://technet.microsoft.com/en-us/library/ee809088.aspx

Network Location Awareness

http://technet.microsoft.com/en-us/library/cc753545(WS.10).aspx

AUTHOR:

Tom Shinder (tomsh@microsoft.com), Technical Writer

REVIEWERS:

Pat Telford, Principle Consultant

Ben Bernstein, Senior Program Manager

Billy Price, Senior Support Escalation Engineer

John Morello, Principle Program Manager

Simon Rabinowitz, Technical Writer

Issue 2 | May 2010 | Bi-Monthly Update

Forefront Edge on the Wiki

The Anywhere Access iX Team has posted ~ 25 articles to the new TechNet Wiki!

Forefront TMG launched a series of articles on the wiki about troubleshooting.

Posted so far in this series, by Rachel Aldam:

· Troubleshooting Forefront TMG URL Filtering common issues

· Troubleshooting Forefront TMG caching

We’d like you to contribute from your experience by adding comments and content to these articles, for the benefit of the Forefront TMG community.

Recently posted Forefront UAG articles include:

· Forefront UAG: About trunks and Forefront UAG: About arrays by Rayne Wiselman

· UAG DirectAccess Group Policy Assignment – Make Sure the Right Policies are Applied by Tom Shinder

· Troubleshooting the “No Usable Certificate(s)” IP-HTTPS Client Error by Tom Shinder

Highlights from Customer Visits

Tom Shinder met with several customers who were interested to deploy Forefront UAG 2010. In particular, they wanted to learn about the technologies and options of Forefront UAG DirectAccess and how it might fit their requirements. During one customer visit, Tom provided a two-day workshop including a deep dive into Forefront UAG DirectAccess, including core infrastructure requirements, IPv6 transition technologies, IPsec, PKI, Active Directory, Windows Firewall with Advanced Security Connection Security Rules, Group Policy, and other key technologies that drive a DirectAccess solution.

The expected results of these visits are more customer pilot deployments of Forefront UAG DirectAccess in the near future!

Step-by-Step Guides

Tom is working with Joe Davies on a new content model with the step-by-step guides which will take on greater prominence in the documentation processes. These guides would transform themselves into “Test Lab Guides” and would lend themselves to a modular or extensible format, so that new technology experiences and demonstrations can be easily included on top of the basic infrastructure. The first experiment is the “UAG DirectAccess with NAP” module. Stay tuned for more details!

The second edition of the Forefront UAG DirectAccess Step-by-Step Guide was released this month, including content on Forefront UAG array configuration, NLB deployment and NAT64/DNS64 functionality. Feedback from different ISVs and OEMs was that the new content helps to demonstrate the value that Forefront UAG provides over the Windows-only DirectAccess solution. While happy with the new content, they are interested in more content in the step-by-step labs, to include the DirectAccess Client Assistant (DCA), NAP, Smart Card/OTP, and SCCM, and other more complex remote management capabilities.

What’s new at the Microsoft Download Center?

Forefront Unified Access Gateway (UAG) Update 1 —Anywhere Access iX released the documentation for Forefront UAG Update 1, including a new Forefront UAG help file (UAG_Help.chm) for download. Special thanks to Rayne Wiselman who lead the effort, and to James Kilner who did most of the writing.

Forefront UAG Update 1 provides:

· Remote Desktop access from Windows Vista and Windows XP—Client endpoints running Windows Vista and Windows XP can now access RemoteApps and Remote Desktops published through Forefront UAG.

· Support for Microsoft SharePoint Server 2010—Forefront UAG now supports SharePoint Server 2010.

· Support for MSOFBA—Forefront UAG now supports the Office Forms Based Authentication protocol to allow rich clients to directly access applications published through Forefront UAG.

· Support for site cookies—Forefront UAG now supports the use of site cookies for non-alternate access mapping applications, in addition to domain cookies.

· Support for large CustomUpdate files—Forefront UAG now supports CustomUpdate files up to 1.5 GB in size.

· Changes in Group Policy Object (GPO) provisioning for DirectAccess clients—Update 1 fixes an issue that caused the export script that creates GPO objects to fail, and an issue that caused the GPO to be applied to all authenticated users in the domain (including computer accounts), instead of to DirectAccess clients only.

What’s new on Forefront Edge Security TechNet?

The following new documentation is live on Microsoft® Forefront Security Edge TechNet:

· Forefront TMG 2010 troubleshooting Web access protection —This series of troubleshooting topics help you determine the cause and resolution of problems you might experience while using Forefront TMG Web access protection.

· What’s new in Forefront UAG Update 1?

· Step-by-step guide for setting up Forefront UAG DirectAccess in a test lab

· Troubleshooting Forefront UAG installation

· Troubleshooting IP address changes

· Forefront UAG operations guide

· Forefront UAG event messages

Forefront Edge in the Community

· Read recent articles by Forefront Edge Security experts in Tales from the Edge:

• Understanding the Re-Injection Mechanism Improvement on Forefront TMG by Yuri Diogenes and Thomas Detzner
• Network Monitor 3.3 RWS Parser Basics, Part 1: Introduction to RWS Protocol Analysis by Jim Harrison
• Network Monitor 3.3 RWS Parser Basics, Part 2: Observing single-connection HTTP traffic by Jim Harrison

· Find answers to questions that MVPs, Microsoft employees, and other experts are asking at the Forefront Edge Security Forums.

· Read the latest postings on the Forefront TMG (ISA Server) product team blog (still one of the most popular blogs visited on TechNet). More than 15 blogs posted recently!

· Read the latest postings on the Forefront UAG product team blog. The popularity of this blog on TechNet is steadily increasing, with almost 10,000 Page Views during March!

· Tom Shinder posted 9 blogs on Forefront UAG DirectAccess issues to The Edge Man!

We’d love to have your comments and feedback to this newsletter. You can contact the Anywhere Access information eXperience Team at uagdocs@microsoft.com or isadocs@microsoft.com. Thanks!

Author:
Michelle Friedmann, Technical Editor, ISD iX: Anywhere Access Team (AAT)

One of the considerations for DirectAccess planning is to decide which DNS names should be resolved internally, by your organization’s internal DNS servers, and which should be resolved externally, using the traditional DNS server configured for your computer’s network interface. This distinction about which DNS server to send each query to is configured on a Windows 7 or Windows Server 2008 R2 computer using entries in the DNS Client resolver’s Name Resolution Policy Table (NRPT).

I won’t go into more details about the specifics of how the NRPT works here, but you can read more about the technology in this TechNet Cable Guy article.

Generally, the task of planning for NRPT entries is pretty easy, because many organizations have a DNS namespace set aside that is normally available only on the intranet – these names are obvious candidates to be referred by the DirectAccess Name Resolution Policy Table to internal DNS servers. a bit more decision-making goes into the process if your organization has a “split brain” DNS. This is a DNS arrangement where you have the same DNS domain available both externally and internally, but the internet-facing version of the DNS domain returns only addresses of public-facing resources, while the internal-facing version provides a full array of internal resource addresses. In these cases, most organizations prefer to have DirectAccess-enabled clients resolve names to the intranet DNS because it has a more fully-populated set of names – the clients will behave like they are always on the intranet.

Without split-brain DNS, there is a natural dividing line between the DNS queries that DirectAccess and the NRPT should send to internal DNS and those that should stay on the internet. But beware! If you have split-brain DNS you may need to make some special allowances for DNS queries that should stay on the internet.

But there are some services where it may be desirable to point clients differently when they are on the intranet than when they are on the internet. For example, an implementation of Outlook Web Access (OWA) may have an internal-facing deployment for web-based email browsing for users on the intranet and a different, more secure implementation for users while they are on the internet, both using the same URL such as http://owa.mycompany.net. These cases call for an exception to be made in the NRPT – essentially an entry that says, “Although I would like you to resolve all names in mycompany.net by querying our intranet DNS servers, if you want to look up owa.mycompany.net, just go to your regular interface-configured DNS server and look it up”.

The most common cases for making an NRPT exception at the customers deploying UAG DirectAccess today are for OWA, for the name of the VPN concentrator for existing VPN solutions, for external-facing Terminal Services/Citrix, and for Office Communications Server (OCS). In many cases where split-brain DNS is not involved, exceptions are not needed, because the external names are already outside the DNS domain of the internal namespace. For example, if your NRPT directs all queries for internal.mycompany.com to DNS servers on the intranet, you will not need to make an NRPT exception for OWA.mycompany.com, but you would need an exception if you wanted OWA.internal.mycompany.com to query internet DNS servers instead of internal ones while clients are internet-connected.

OCS is a special case. The current version of OCS (2007 R2) does not support connections over IPv6, not even over UAG-DirectAccess’ NAT64 function. Because all DirectAccess traffic is either end-to-end IPv6 or is client-to-UAG IPv6 and UAG-to-resource IPv4 using NAT64, OCS just does not work if the traffic is sent through the DirectAccess server.

Fortunately, most OCS deployments also have external-facing components that users can access directly on the internet. But in order for external OCS to work properly, you must define your NRPT exceptions properly, so your DirectAccess-enabled clients don’t try to resolve intranet names for your OCS components. We want them to go to the internet-facing servers while outside, even if DirectAccess blurs this distinction and makes the clients behave more like they are on the intranet.

An NRPT exception consists of a fully-qualified DNS name that has no associated DirectAccess DNS Server address. This tells the DNS client to resolve the excepted name using its normal interface-configured DNS server instead of following the more general rule and sending the query to the internal DNS server.

The example below, output from the netsh namespace show policy command on a DirectAccess-enabled client, shows an exception followed by a more general rule:

Settings for sip.mycompany.net

----------------------------------------------------------------------

Certification authority                 :

DNSSEC (Validation)                     : disabled

DNSSEC (IPsec)                          : disabled

DirectAccess (DNS Servers)              :

DirectAccess (IPsec)                    : disabled

DirectAccess (Proxy Settings)           : Bypass proxy

Settings for mycompany.net

----------------------------------------------------------------------

Certification authority                 :

DNSSEC (Validation)                     : disabled

DNSSEC (IPsec)                          : disabled

DirectAccess (DNS Servers)              : 2001:db8:e0:7979::100:2

                                          2001:db8:e0:7979::100:1

DirectAccess (IPsec)                    : disabled

DirectAccess (Proxy Settings)           : Bypass proxy

For OCS, there are a set of seven standard names that you may need to include as exceptions in a DirectAccess NRPT configuration. These are:

      _sipinternaltls._tcp.<yourdomainname>

      _sipinternal._tcp. <yourdomainname>

      _sip._tls. <yourdomainname>

      _sip._tcp. <yourdomainname>

      sip. <yourdomainname>

      sipinternal. <yourdomainname>

      sipexternal. <yourdomainname>

Additionally, there are three external DNS names that your clients need to resolve in order to locate external-facing OCS Server components. The names that are configured for your OCS Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server can be set to whatever you want, so you will need to look them up in your OCS configuration’s Edge Interfaces properties as shown in the screen shot below. These DNS names are also discussed in this OCS TechNet article.

These items above assume that the OCS client is using the default automatic discovery mechanisms to get their configuration. It is also possible that an organization may choose to use manual configuration for the initial configuration of OCS. The specific names used in manual configuration of the connection settings can be delivered through Group Policy or be configured directly at the OCS client. You can see if there is an additional name that you might need to make an exception for in your NRPT by examining the OCS settings from the OCS options\personal\advanced dialog, like the one shown below.

Once you have figured out the NRPT exceptions that you need to make to suit your organization’s external-facing service names, you can set them up in the UAG DirectAccess Infrastructure Server Configuration step, like shown below.

Hopefully, this can help you smooth over any deployment wrinkles associated with OCS as you deploy UAG DirectAccess, and can help you understand situations where other NRPT exceptions might be needed.

Author:
Pat Telford, Principal Consultant, Microsoft Consulting Services

Forefront UAG tracing is available

UAG 2010 introduced a new trace mechanism that is based on Event Tracing for Windows (ETW); a high-performance, low overhead, scalable tracing mechanism that is provided by the Windows operating system. UAG tracing provides detailed failure and debugging information in a binary format. This binary information can be converted into a readable text format using UAG trace symbols. UAG tracing symbols are now available on Download Center (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fc052e67-2a04-4058-b326-9d92aa67b2c4). Forefront UAG tracing can be run on the both UAG server, and on client endpoint devices connecting to Forefront UAG resources.

The following items are available on the Download Center page:

·    A set of .tmf files in a ZIP archive – cumulative .tmf files. This archive will be updated with every UAG release.

·    A EULA license – this license is also included in the tmf ZIP archive

·    A document with instructions for configuring and running tracing

Versions of .tmf files provided by this download are as follows:

·    Forefront UAG RTM ((v4.0.1101.000)

·    Forefront UAG Update 1 (v4.0.1152.100)

Thanks,

Ran Dolev

Yossi Yossifon