Microsoft Forefront UAG Product Team Blog

KB: DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010

Forefront UAG Team — Tue, 15 May 2012 17:19:43 GMT

Here’s a new Knowledge Base article we published. This one describes an issue where DirectAccess Manage Out fails for any non-ICMP traffic in UAG 2010.

=====

Symptoms

DirectAccess Manage Out does not work for any non-ICMP traffic in Microsoft Forefront Unified Access Gateway 2010. Outbound connections to external DirectAccess client machines fail for any traffic except for ICMP. If IPsec auditing is enabled you may see the following error when attempting to access the DirectAccess client:

4984 "An IPSec extended mode negotiation failed"

Cause

This issue can be caused by custom security policies regarding the local security rights for DirectAccess Manage-Out server and clients (e.g. modifying the setting "Access this computer from the network").

Manage-out connections require the ability of the source computer account and user account to authenticate IPsec connections to the remote DirectAccess client. Even though the IPsec tunnel is established from the DirectAccess server to client, the authentication occurs based on the internal source machine/account (impersonation).

The security policy for “Access this computer from network” controls the ability to authenticate and access system services on remote computers. This source machine/account must have this right granted for the remote resources for the DirectAccess Manage-Out capability to function. If the DirectAccess server machine account and the machine account of the internal source server used in impersonation do not have permissions to access the DirectAccess client machine from the network then IPsec authentication failures will occur.

Changes had been made to the local security policy which altered the default permissions for this access right. Everyone and Users groups were removed from the local security setting “Access this computer from network”.

Resolution

Reset the Local Security Setting for "Access this computer from the network" to the default configuration. By default this includes the following groups: Administrators, Backup Operators, Everyone, Users. The default setting is the only configuration which has been tested and verified for DirectAccess Manage Out connectivity.

More Information

2663354 - Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments : http://support.microsoft.com/default.aspx?scid=kb;EN-US;823659

=====

For the most current version of this article please see the following:

2704138 - DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Behavior of the “Logoff URL” option

Forefront UAG Team — Fri, 11 May 2012 16:01:02 GMT

Symptoms:

You’ve published an internal Web resource. Your users can successfully authenticate and access the site. However, they may discover that selecting any link from a particular page in the site inadvertently sends them back to the initial UAG login form. If they provide their credentials again, the select page loads correctly. If they navigate back to the page in question and again select any link on the page, they are again sent back to the UAG login form.

Potential Cause:

UAG has detected a request that contains your custom “Logoff URL” and has terminated the session and is now un-authenticated. Any continued access to the site will need to be authenticated again.

More information:

In the Trunk configuration properties page, under the Authentication tab, you’ll find the “Logoff URL” setting. The default Logoff URL is “/InternalSite/LogoffMsg.asp”. If UAG detects a client request that contains this URL, UAG will terminate the clients’ session.

This setting is configurable and you can specify a custom value to be used as the logoff mechanism. For instance, if your published web application has its own logoff option, you can specify your applications’ logoff URL to terminate the session. For example, your applications’ logoff may be something like “logoff.jsp”. So you might enter “logoff.jsp” as the “Logoff URL” option. With this value in place, the expectation is that the session will not be terminated until the client makes a request for “logoff.jsp” (or the session times out").

This still doesn’t explain why your users are inexplicably required to re-authenticate when selecting various links in the page. After all, they’re not selecting the applications’ logoff option. In fact, you may have trouble-shot the issue using a web capture tool such as HTTPWatch or Fiddler…and you have verified that the client does not send a request for “logoff.jsp”, yet you can see that the session has ended and user is required to re-authenticate.

The root of the problem lies in the fact that UAG treats the “Logoff URL” value as a string. Therefore, any client request that contains this “string” will terminate the session. Even if the value you specify for “Logoff URL” is a substring contained in a client request, the session will be terminated.

For example:

The “Logoff URL” value entered is “logoff.jsp”. Logoff.jsp resides in the following location on the server:

/folderA/logoff.jsp

The client sends a request for the following:

/folderB/ignorelogoff.jsp

UAG detects the string “logoff.jsp” in the request for “/folder/ignorelogoff.jsp” and terminates the session.

Resolution:

Make sure your custom “Logoff URL” value is not a sub-string of any other client request. For example, using the above scenario, you could specify “/logoff.jsp” (i.e. add a forward slash) as your “Logoff URL”.

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

UAG Web Monitor shows “There are no events to display”

Forefront UAG Team — Tue, 08 May 2012 15:06:58 GMT

Symtoms:

When starting Web Monitor and selecting any option under the Event Viewer category, the Web Monitor displays the following message:

"There are no events to display"

Additionally, if you have a UAG Array and you select "Current Status" under the Array Monitor category, you may see that the UAG nodes show a Synchronization Status of "error".

While troubleshooting the issue, the UAG tracing output may show an entry similar to the following:

[0]21FC.2F28::<Date/Time> [MonitorHelper]The dummy request failed: System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it <UAG server internal IP address>:50002

Note: For more information on UAG tracing, please see my teammate Ben Ari’s blog on UAG Tracing:

http://blogs.technet.com/b/ben/archive/2010/09/03/uag-tracing-made-simple.aspx

More information:

By default, UAG servers are configured to log UAG related events to the following location:

<UAG install folder>\logs\Events

You can then use Web Monitor to view and filter those logged events. See the following TechNet article for more information related to UAG logging:

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

By default, both the LOGS folder and EVENTS folder have the following Security Permissions:

SYSTEM - Full Control

NETWORK SERVICE - Full Control

Administrators (<localserver>\Administrators) - Full Control

Users (<localserver>\Users) - Read & execute, List folder contents and Read

Cause:

You may see the above Web Monitor errors if the NETWORK SERVICE does not have the proper permissions for the Logs and/or Events folders.

Resolution:

Make sure that the NETWORK SERVICE has Full Control permissions for the Logs and/or Events folders (including subfolders and files).

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

SSO (Single Sign On) not working for a published Web Application with UAG

Forefront UAG Team — Tue, 24 Apr 2012 16:55:00 GMT

Introduction:

We had an application published on Microsoft Forefront Unified Access Gateway 2010 (UAG). Single Sign On (SSO) for that particular application on UAG was not working. We were using 401 to delegate credentials on the Applications Publishing Rule on UAG.

Scenario:

The issue was specific to one particular application published through UAG. SSO for the other published applications was working fine, so there was definitely something different on that particular server.

The users were getting the following error when trying to access the application externally:

You do not have permissions to view this folder or page

Troubleshooting:

We gathered a UAG trace and its analysis showed the following errors:

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CSSPINegStep::ProcessNegStep HTTP401Authentication.cpp@1340] ERROR:HTTPAuth::CSSPINegStep::ProcessNegStep - ERROR: InitializeSecurityContext failed with error code 0x80090302 (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10)

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CNTLMHandler::Negotiate HTTP401Authentication.cpp@1515] ERROR:HTTPAuth::CNTLMHandler::Negotiate - conversation failed, resetting state (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10

Error Code 0x80090302 resolves to SEC_E_UNSUPPORTED_FUNCTION.

Researching the message led us to an article on TechNet that stated:

According to InitializeSecurityContext (NTLM) documentation, a call to this method will return a SEC_E_UNSUPPORTED_FUNCTION when : A context attribute flag that is not valid (ISC_REQ_DELEGATE or ISC_REQ_PROMPT_FOR_CREDS) was specified in the fContextReq parameter.

Network traces confirmed that it was exactly the behavior mentioned above, as the backend web server was not setting the "128-Bit Encryption" flag on its reply in the NTLM negotiate header. In a Network Monitor capture, this is what that looks like:

Request sent from UAG to the web server:

Response from the web server:

As it turns out, the backend server does not support 128-bit NTLM encryption, but UAG was set to require it.

The ideal way to solve this is by configuring the backend server. If, however, the backend server cannot support 128-bit, we can work around this by disabling 128-bit in UAG. Disabling 128-bit on the UAG server should only be done as a last resort. This is the procedure:

1. Open the local group policy editor on the UAG server

2. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

3. Double-click the option “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers":

4. Uncheck both options and click OK. The setting will change to read “no minimum”:

5. Exit the group policy editor.

Author:

Nitin Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Ophir Polotsky
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Ben Ari
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

MS12-026: Description of the security update for Microsoft Forefront Unified Access Gateway 2010 Service Pack 1: April 10, 2012

Forefront UAG Team — Wed, 18 Apr 2012 22:21:55 GMT

In case you happened to have missed the announcement last week, Microsoft has released security bulletin MS12-026 - Vulnerabilities in Forefront Unified Access Gateway (UAG) Could Allow Information Disclosure (2663860). To view the complete security bulletin, visit the following Microsoft website:

http://technet.microsoft.com/security/bulletin/MS12-026

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

KB: Upgrading to Microsoft Forefront Unified Access Gateway 2010 Service Pack 1 fails with error 1603

Forefront UAG Team — Tue, 20 Mar 2012 15:23:38 GMT

Here’s a new Knowledge Base article we published today. This one talks about an issue where upgrading to Microsoft Forefront Unified Access Gateway 2010 SP1 fails with error 1603 and rolls back:

=====

Symptoms

When upgrading to Microsoft Forefront Unified Access Gateway 2010 (UAG) Service Pack 1 (SP1), the upgrade fails with error 1603 and rolls back. You may also see the following in the UAG SP1 Setup log files for UAG which are located at %ProgramData%\Microsoft\UAG\Logs:

Hybrid_Default_Web_App_Access.
MSI (s) (48!98) [08:51:45:640]: Closing MSIHANDLE (577708) of type 790531 for thread 5016
MSI (s) (48!98) [08:51:45:662]: Creating MSIHANDLE (577709) of type 790531 for thread 5016
UAG CA (Info): Error: Caught error (will rethrow after rollback): System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at Microsoft.UAG.Transformer.Core.PolicyConverter.ProcessTrunk(String trunkName, XmlNode trunkNode, String policySettingsNodeXPath)
at Microsoft.UAG.Transformer.Core.PolicyConverter.ConvertData()
at Microsoft.UAG.Transformer.Core.SchemaConversionRuntime.Run()
MSI (s) (48!98) [08:51:45:662]: Closing MSIHANDLE (577709) of type 790531 for thread 5016
MSI (s) (48!98) [08:51:45:663]: Creating MSIHANDLE (577710) of type 790531 for thread 5016
UAG CA (Info): Info: Firing ProgressChanged event: Step: 0%, Description: 'Conversion aborted due to error, Rolling back.'.

Cause

This can occur if UAG is configured with the Sharepoint-specific download and upload endpoint policies prior to running the SP1 upgrade. The installation process raises an exception and rolls back when the name of one (or more) of the existing standard policies is in use by an application.

Resolution

To resolve this issue, create new custom policies with the same data and use those instead of the Sharepoint-specific download and upload endpoint policies.

More Information

For more information see the following:

Configuring Forefront UAG access policies : http://technet.microsoft.com/en-us/library/dd857309.aspx

=====

For the most current version of this article please see the following:

2685784 : Upgrading to Microsoft Forefront Unified Access Gateway 2010 Service Pack 1 fails with error 1603

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

KB: Session timeout does not work as expected when publishing Exchange Outlook Web Access with UAG 2010

Forefront UAG Team — Wed, 07 Mar 2012 19:41:50 GMT

Here’s a new Knowledge Base article we published today. This one talks about an issue where the session timeout doesn’t work as expected when publishing OWA with UAG 2010:

=====

Symptoms

Microsoft Forefront Unified Access Gateway 2010 (UAG 2010) allows a user to define Inactive session timeout. The Inactive session timeout defines the maximum time a session can be inactive before it times out (see http://technet.microsoft.com/en-us/library/ee406216.aspx). When publishing Microsoft Exchange Outlook Web Access 2010 (OWA 2010) using UAG 2010, the session may stay active even if there is no activity for longer than the value defined in the "Inactive session timeout" field.

Cause

The UAG 2010 configuration has a setting for Ignore requests in timeout calculations that contains a list of URLs that are ignored in the calculation of the Inactive Session Timeout settings (see http://technet.microsoft.com/en-us/library/ee406216.aspx#BKMK_Global).
When a client issues a request to one of the URLs and methods define in this list that contain a body (like in a POST method), the request will still be counted as active even if it matches the settings in this list. In addition, some URLs are missing from the default list for OWA 2010.

Resolution

To resolve this issue complete the following:
1. Install Service Pack 1 Update 1 for Forefront Unified Access Gateway (http://support.microsoft.com/kb/2585140)
2. After installing SP1, add the following URLs and methods to the Ignore requests in timeout calculations settings for the "Microsoft Exchange Server 2010" application:

=====

For the most current version of this article please see the following:

2621269 : Session timeout does not work as expected when publishing Exchange Outlook Web Access with UAG 2010

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

DirectAccess Connectivity Assistant polling interval

Forefront UAG Team — Tue, 20 Dec 2011 13:59:00 GMT

We have recently had a number of customers inquire about the default polling interval for the DCA client. The polling interval of the DCA client is 30 seconds.

More Info

One of the primary functions of the DirectAccess Connectivity Assistant is to indicate the operational status of DirectAccess by using an icon in the notification area. The DCA client is deployed with connectivity verifiers that are configured to poll specified internal resources. These resources can consist of a combination of HTTP/HTTPS and File/SMB resources.

The DCA client polls these resources once every 30 seconds to verify connectivity. The polling interval is not configurable and is not “auto-adjusted” by the DCA client. For more information on the DirectAccess Connectivity Assistant, please see the following article:

DirectAccess Connectivity Assistant 1.5 Deployment Guide

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

The UAG DirectAccess Web Monitor shows “Network Security” as Not Healthy

Forefront UAG Team — Thu, 15 Dec 2011 16:50:01 GMT

Symptom:

When checking the Current Status of DirectAccess using the Web Monitor, you may find that the report shows “Network Security” as Not Healthy.

More Information:

When activating the UAG DirectAccess configuration, the internal interface selected in the UAG DirectAccess wizard is configured with IPsec Denial of Service Protection (DoSP or ipsecdos). DoSP helps to prevent internal computers from being affected by denial of service attack against IPv6-based IPsec computers on your network (i.e. DA clients)

DoSP typically runs on a computer that connects to two or more network, where the networks are Public or Private. If IPSec Denial of Server Protection is not enabled on the interface, the DirectAccess Web Monitor status may show “Network Security” as Not Healthy.

Possible causes:

1. IPSecdos may not be enabled on the Internal ISATAP interface

Running ‘netsh ipsecdos show interface’ will the display the list of interfaces with IPSecdos enabled.

For example:

However, you may find that no “Internal interfaces” are listed in the output. If there is no internal ISATAP interface listed, this may be the cause of the problem. To alleviate this problem, you first need to determine the servers’ internal ISATAP interface. Running ‘ipconfig/all’ will display all of the active/usable interfaces on the machine. The internal ISATAP interface will typical have an IPv4 DNS server configured. Once you’ve determined the internal ISATAP interface, run the following command:

Netsh ipsecdos add interface name=”<Friendly name of the interface>” type=internal

Note: Following my example above, the friendly name would equal “isatap.<2DED6CDA-E410-46BE-B358-36B488D4797C>”

2. The UAG servers 6to4 and/or ISATAP interfaces are missing/unusable.

An issue existed in Windows 2008 R2 RTM where, under certain reboot scenarios, a new 6to4 and/or ISATAP adapter may be created. Essentially, when the computer restarts, the Plug and Play service shuts down before the process to enable the “reuse” of the 6to4/ISATAP adapter occurs. Therefore, the 6to4/ISATAP adapter cannot be reused after startup so a new, additional 6to4/ISATAP adapter is created.

Normally, the UAG server should have one virtual 6to4 adapter and three ISATAP adapters (one for each of the two physical NICs and one for the SSL tunnel adapter).

If your computer has experienced this issue, you may notice multiple 6to4 and/or ISATAP virtual adapters listed when running ‘ipconfig /all’. If you notice multiple 6to4 adapters listed, you may find that one or more of them may have a Media State of “Media Disconnected”. Additionally, you may notice multiple ISATAP adapters (i.e. 4 or more).

So why does this cause so much grief for UAG DirectAccess? When UAG DirectAccess is configured, Enabled and Activated, it queries the available adapters and creates the DA policy and forwarding statements based on these interfaces. This includes the ‘useable’ 6to4 and ISATAP interfaces that are available when DirectAccess is Enabled.

If your server experiences this issue during a reboot, the new ‘reusable’ interfaces that are created do not have ipsecdos enabled by default.

Steps to correct the issue:

Typically, there are two avenues you can take. The first is to ‘clean up’ all the 6to4 and ISATAP interfaces, and allow them to be recreated. The second is to configure DirectAccess to make use of new “useable” interface<s> available; while leaving the original ‘non-reusable” interface intact. Both of these steps will enable ipsecdos on the new ‘reusable’ interface<s>.

1. Clean up the interfaces

a. Open the UAG console, select DirectAccess and click the Disable button. After DirectAccess is disabled, Activate and then close the UAG console.

b. At an Administrative command prompt, run the following command: ‘set devmgr_show_nonpresent_device=1’

c. Open Device Manager and select View-Show hidden devices. Then expand ‘Network Adapters’ and delete all 6to4 and ISTAP adapters listed.

d. Open the UAG console, select DirectAccess and click the Enable button. After DirectAccess is enabled, Activate the configuration.

2. Configure UAG to make use of the new (i.e. reusable) interfaces<s>

a. Open the UAG console, select DirectAccess and click Disable button. After DirectAccess is disabled, Activate the configuration.

b. In the UAG console, select DirectAccess and client the Enable button. After DirectAccess is enabled, Activate the configuration.

Additional information:

This Windows 2008 R2 RTM issue has been addressed in Windows 2008 R2 Service Pack 1. However, it should be noted that process of installing Service Pack 1 and rebooting may put the server in this state again. If so, follow the steps above again to correct the behavior. The issue should then be alleviated moving forward.

Author

Richard Barker - Sr Security Support Escalation Engineer, Microsoft CSS Forefront Security Edge Team

SSO to SharePoint 2010 through UAG when using two authentication schemas

MeirM [MSFT] — Tue, 15 Nov 2011 17:05:00 GMT

Hi everyone, this is Dror from the Forefront UAG product group.

One of our customers ran into an issue with their SharePoint deployment and we thought it is worth sharing with you all the ways that UAG can be leveraged.

Let’s assume a topology like this one:

In this case, two different categories of users gain access to the SharePoint farm via UAG: internal users (while outside of the company network), and partner users. Windows Integrated authentication is used in SharePoint for internal users, while form-based authentication is used for partner users. However, the SharePoint URL is the same for both types of users. As such, we have a case where SharePoint 2010 is configured with two authentication schemes for the same Intranet Zone.

Normally, in SharePoint 2010 in a scenario where you configure more than one authentication per zone, users are presented with a form where they need to choose which authentication method to use:

Till now everything is cool…

Most customers wish to have a single sign-on (SSO) experience for their users. That means that once users are logged in to UAG, they will not be prompted for credentials again. This is the SSO functionality that UAG offers. The question we faced in this specific case was: how can we achieve the same end-user experience of no additional prompts to the end-user, in this case where the “Multi-authentication selection” page is required by SharePoint?

There are 2 ways to handle this “Multi-authentication selection” page:

1. Auto-submit the page with a pre-defined selection – The UAG administrator can decide on the selected option by applying a custom setting. In this case, when the page sent by the SharePoint server is received by UAG, and before UAG sends it on its way to the client browser, UAG injects into the “Multi-authentication selection” page some code, in order to cause the page, as soon as it’s displayed on the user’s browser, to be automatically submitted with a predefined option, either Windows Authentication or Forms Authentication, without requiring any end-user interaction.

Here is a sample of this customization, using a custom AppWrap file, which shows the steps. Note that this example cannot be used ‘as is’ since all the values in the SEARCH and REPLACE fields need to be BASE64-encoded.

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

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<DATA_CHANGE>

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

<SAR>

<REPLACE encoding="base64"><option selected="selected" value="Forms">Forms Authentication</option></REPLACE>

</SAR>

<SAR>

function FormLoginSubmit()

{

var o = document.getElementById('ctl00_PlaceHolderMain_ClaimsLogonSelector');

var evt = document.createEventObject();

o.fireEvent('onchange',evt);

o=null;

}

</SCRIPT>

var gSafeOnload = new Array();

function FormLoginOnload()

{

for (var i=0; i < gSafeOnload.length; i++)

{

gSafeOnload[i]();

}

if (window.onload) {

gSafeOnload[0] = window.onload;

gSafeOnload[gSafeOnload.length] = FormLoginSubmit;

window.onload = FormLoginOnload;

}

else

{

window.onload = FormLoginSubmit;

}

</SCRIPT>

</body></REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

2. Auto-submit the page with a selection based on a session (user) parameter – This is an extension of the first method, as shown above. Using this method, the selection between Windows or Forms authentication is not pre-defined and constant for all UAG sessions, and instead it can be dynamically set for each UAG session. The UAG administrator can set a parameter with one of two values, which UAG will later use to decide which authentication method to choose when submitting the “Multi-authentication selection” form. This parameter is stored within the context of the UAG session and it can be set by using the UAG customization mechanism. UAG makes its decision using the conditional AppWrap mechanism.

In the example below the Contoso administrator uses a custom ValidateSuccess.inc file to insert a parameter named AuthenticationMethodVar into the UAG session. In this file, VBScript code is used to check if the user’s UPN is part of the Contoso domain. If yes, the value of AuthenticationMethodVar is set to WINDOWS, otherwise it is set to FORM. In the custom AppWrap file we use this value to decide which of the authentication methods will be selected.

' Add a session variable based on user internal/external

MyUserUDomain = “contoso\”

if Left(Session("LeadUser"), Len(MyUserUDomain)) = MyUserUDomain then

SetSessionParam g_cookie, “AuthenticationMethodVar”, “FORM”

else

SetSessionParam g_cookie, “AuthenticationMethodVar”, “WINDOWS”

end if

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

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<DATA_CHANGE>

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

<REPLACE encoding="base64"><option selected="selected" value="Windows">Internal User</option></REPLACE>

</SAR>

<REPLACE encoding="base64"><option selected="selected" value="Forms">Partner User</option></REPLACE>

</SAR>

<SAR>

function FormLoginSubmit()

{

var o = document.getElementById('ctl00_PlaceHolderMain_ClaimsLogonSelector');

var evt = document.createEventObject();

o.fireEvent('onchange',evt);

o=null;

}

</SCRIPT>

var gSafeOnload = new Array();

function FormLoginOnload()

{

for (var i=0; i < gSafeOnload.length; i++)

{

gSafeOnload[i]();

}

if (window.onload) {

gSafeOnload[0] = window.onload;

gSafeOnload[gSafeOnload.length] = FormLoginSubmit;

window.onload = FormLoginOnload;

}

else

{

window.onload = FormLoginSubmit;

}

</SCRIPT>

</body></REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

Once this form is submitted, the flow will continue according to the selection submitted back from the client browser (remember, the end-user has no say and no interaction with the form, as the selection is made on the end-user’s behalf by the UAG administrator, by using one of the two methods described above). For Windows Integrated authentication, the SharePoint server returns an HTTP 401 response to which UAG answers on behalf of the user. For FBA, the SharePoint server returns its authentication form, which UAG handles in its normal way of handling SSO to backend web sites that use FBA – UAG injects some content into that form, before sending it to the browser, then, once the browser receives it from UAG, it renders the page and immediately submits it back, without any user interaction (due to code injected by UAG) and SSO is completed.

Note that in order for both of these options to work, in the UAG Management console the authentication for the SharePoint application should be configured to Use SSO for Both (which means UAG should be ready to handle HTTP 401 responses, as well as the HTML form of the SharePoint server).

Author:

Dror Melovany, Software Development Engineer, Microsoft Forefront UAG

On a DA client, the DCA shows a red X or a yellow exclamation mark even when the connection works fine.

MeirM [MSFT] — Wed, 09 Nov 2011 18:00:34 GMT

A common situation with UAG is that when a DA client connects, he sees a red X or a yellow exclamation mark even when the connection is actually working fine.

This type of thing can happen if you have configured the DA connectivity verifiers to use the URL of the NLS server. The NLS server is normally listed as an exclusion in the NRPT, because we need it to not be available to DA clients, as its unavailability is what triggers the DA client to initialize the DA connection:

This issue sounds like a problem with the connection itself, but we can see it is not because client can clearly connect to other internal resources, and so the DCA error is a false-negative.

This is rather simple to address. Simply use a different server as a connectivity verification method!

To do this, follow these steps:

1. Open the UAG Configuration console

2. Go to the Client Connectivity Assistant Configuration

3. Go to page 2 of the wizard – “Connection Verification”

4. Remove the NLS URL, and add in a different server that should be available (the organization’s SharePoint server, or some other website, perhaps)

5. Complete the wizard

6. Activate the configuration.

7. Re-run the Group Policy script on UAG, and deploy the new policy to clients.

Here are some additional resources which talk about NLS and NRPT in details:

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

http://blogs.technet.com/b/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx

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

Blog post written by Nitin Singh

Lessons from the Field and Best Practices for Active Directory Authorization on Unified Access Gateway 2010(UAG)

MeirM [MSFT] — Mon, 31 Oct 2011 20:45:00 GMT

An issue that has been experienced by many UAG customers is a situation where the UAG portal becomes unresponsive while users try to access it externally. This can also manifest itself as a slow login.

When the user clicks on the ‘Log-on’ button on the Portal Page, to check whether the user is an Authenticated user or not UAG checks all its ‘Authentication Repository’ settings to get the Domain Controllers information and the other settings associated with them. One of those settings is the ‘Level Of Nested Group’. This setting, if not set correctly, can cause a lot of slow Log-On Issues and the UAG Portal becoming unresponsive as well.

Let me share a scenario with you, in which a customer reported a similar issue and how we fixed it.

Scenario:

We had an issue where the UAG Portal Page was becoming unresponsive while trying to access it externally. Restarting the UAG services would temporarily resolve it, but it would recur on subsequent logins.

Troubleshooting:

The issue manifested itself as the UserMgrCom.exe process causing a CPU Spike of around 100% CPU utilization. When we checked the Authentication Repository settings in the UAG console we noticed the following setting:

As you can see in the above screenshot the value of Level of nested groups was defined as 1000. However, Ideally, this value should not be configured above 2 or 3. Group nesting relates to group authorization configured on applications on the portal. If the applications are configured to allow all users to be authorized there is no need for any nesting. On the other hand if groups are used for granular application authorization then group nesting would only be required if the group(s) selected for authorization are groups that are nested (members of) another group in Active Directory. If the groups are direct user containers and not group members, nesting is also not required. Setting the level of nesting to anything other than its default tells UAG to preform recursive queries on every group a user is a member of until the level of nesting is reached. This set of recursive query is incredibly resource and time intensive both to UAG and to the Domain controllers that are being accessed.

In this case, because it was set to such a high value of 1000, it was causing UAG to perform unnecessary checks for Group Memberships for users and this was causing the UserMgrCom.exe to Spike, and the Portal to become unresponsive.

Author:

Nitin Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Dan Herzog
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Ben Ben Ari
Security Sr. Support Engineer
Microsoft CSS Forefront Security Edge Team

Accessing Enterprise vault archived emails through UAG

MeirM [MSFT] — Thu, 01 Sep 2011 17:26:26 GMT

I recently worked on a case where the issue was that users could not access Enterprise vault archived emails in OWA Published through UAG. Enterprise Vault is an email archiving software from Symantec and is used as an add on with OWA to access archived emails. Since it is used along with OWA, which we publish through UAG, we also need to configure UAG to allow access to the Enterprise Vault URLs.

Scenario: The admin has configured UAG to publish OWA. He was also trying to publish Enterprise Vault through UAG to access archived emails along with OWA. However, archived emails were not showing up properly, the image hyperlinks for it were not showing and archived emails were inaccessible.

Troubleshooting Approach and Resolution

1. In order to troubleshoot this, we reproduced the issue on a client machine, and then looked at the web monitor logs on the UAG server. This is what we found

“A request from source IP address 18.9.7.2, user test2 on trunk portal; Secure=1 for application Exchange 2010 OWA of type ExchangePub2010 failed. The URL /owa/EnterpriseVault/Exch2010/v9.0.1.1073/scripts/xyz.js contains an illegal path. The rule applied is Default rule. The method is GET.”

2. We checked the Advanced Trunk configuration and the URL set, and found following in the EnterpriseVault rule, which was created by the customer:

i.e. the path /enterprisevault/.* was not correct , as the request in the web monitor log had the path of “/owa/EnterpriseVault/…” .This means we need to add /owa before /EnterpriseVault/.*

Apart from that we also needed to change the name of the rule. 1^st, it needs to be named after the Exchange applications convention (ExchangePub2010_RuleXX), and 2^nd, have a high number so that it does not get overwritten by UAG if the default rule-set changes. We changed our rule to ExchangePub2010_Rule99, and access to Enterprise Vault was successful.

More about Rule name definition

A URL Set rule has two parts:

a. Application: This is to define the application for which this rule is configured. UAG looks for the URL throughout the URL Set rules, and will determine the application type based on that match. If the Rule name does not match any existing application type, UAG will not know what to do. In this case, it is ExchangePub2010_Rule99

b. Rule(number): Keyword Rule along with number. By default ExchangePub2010 has 42 rules, so in order to make sure this rule is not overwritten with future updates of UAG, I used a large number (i.e. 99) and the resulting rule name is ExchangePub2010_Rule99

Blog post written by Suraj Singh

Microsoft Forefront UAG 2010 SP1 has passed Common Criteria Evaluation Assurance Level 2+ (EAL 2+)

MeirM [MSFT] — Thu, 11 Aug 2011 19:36:24 GMT

I’m happy to announce that Microsoft Forefront UAG 2010 SP1 has passed Common Criteria Evaluation Assurance Level 2+ (EAL 2+).

The certification work has been performed by the Federal Office for Information Security (BSI), the Common Criteria certification body of the German government and TÜViT Evaluation Body for IT security which evaluates products worldwide according to the ITSEC and the Common Criteria (CC). More information is available here.

Here is a scan of the certificate:

Detective agency

MeirM [MSFT] — Wed, 08 Jun 2011 18:24:04 GMT

As you probably know, one of UAG’s most important features is the endpoint detection mechanism. This engine runs a special detection script on connecting clients, which reports back to UAG certain properties of the endpoint. Then, the administrator can configure the UAG to reject or accept certain endpoints based on the detected properties.

A lesser known aspect of endpoint detection is the ability to create custom detection scripts, which can detect properties not originally covered by the default detection script. Our documentation discusses how to create a script, but provides little detail as to how they actually work. Here’s the low-down how-to!

The detection mechanism works by running a special VB-Script file on the client endpoint, so the customize it, you need to create your own script. What this script does is collect information, and send it back to UAG by populating certain variables, and then, UAG can use these variables as a basis for a decision as to ACCEPT or REJECT that endpoint. The process for creating a custom detection is:

1. Decide what values you want to collect from the endpoint

2. Write your custom script, and put it in the designated folder on UAG

3. Configure UAG to use that script

4. Write a custom endpoint policy to evaluate the custom values

5. Assign the custom policy to your trunks and applications

The values that you can collect may be anything you want, as long as you can collect it on the endpoint. You then send these values to UAG by using the following syntax:

Results("System_Windows_Version") = Whale.WindowsVersion

Results("Network_Domains_NetBIOS")=Whale.System.MachineDomain

What this does is query the special COM object that UAG installs on the client, and then put the result in the parameter list using the RESULTS function. The above are taken directly from the default detection script (which you can find and on your own server under <UAG Path>\von\InternalSite\Detection.vbs, but you could also use your own parameter names. You do need to make sure that the parameter names do not contain spaces, as this makes writing the endpoint policy a bit of a problem.

Another thing that’s important to note is that the detection script runs on the client endpoint under the context of the browser, and as such, it is restricted by default as part of the browser’s design. This means that your script can’t just use any old COM objects that you can use when running regular scripts on your computer. For example, you can’t use the FileSystemObject object and methods to read or write files to the client system. However, the built in COM object WHALE does provide some useful functionality. Here are some of methods you can use. Please refer to the default detection script to read more about how they work:

AttchWiperObj.CacheIE2(Parameters)

AttchWiperObj.CacheIE3(Parameters)

Whale.AntiVirus.NortonEnabled

Whale.AttachmentWiperVersion

Whale.BrowserPID

Whale.DetectorVersion

Whale.ExternalHost

Whale.ExternalHostname

Whale.FileSystem.DateLastModified(AddSlashToPath(installDir) & "main.dll", "")

Whale.FileSystem.Exist(exepath & "ccSvcHst.exe")

Whale.FileSystem.GetINIFileString(AVInstallDir & iniFileName, "AntiVirus_Tables", "Version")

Whale.FileSystem.ProductVersion(item.ExecutablePath))

Whale.PFW.McAfeeEnabled(win9x)

Whale.Processes.Filter("ATRACK.EXE")

Whale.Registry.RegRead(rkHKEY_LOCAL_MACHINE,Regpath ,"enabled")

Whale.SecurityCenter

Whale.ShowDebugMessages = False

Whale.SSLVPNVersion

Whale.System.ExpandEnvironmentStr("ALLUSERSPROFILE")

Whale.System.IsModuleLoaded("syfort.dll")

Whale.System.LoggedOnUserPrivileges

Whale.System.MachineDNSSuffix

Whale.System.MachineDomain

Whale.WindowsServicePackVersion

Whale.WindowsSoftware

Whale.WindowsVersion

Whale.XPSP2Check

So, for example, if you want to check if certain software is installed on an endpoint, all you have to do is figure out the location of a file that would indicate that the application is there, and use the Whale.FileSystem.Exist method to check it. Alternatively, if you know a specific registry key that indicates the software is there, you can look for that using the Whale.Registry.RegRead method. Ultimately, you need to keep in mind that your control of the user’s system is limited, and all of these values can be spoofed by an advanced and savvy user, so it’s worth taking that into account.

To debug your script, you can use the command Whale.DebugEcho, like this:

Whale.DebugEcho "Starting detection at " & now

However, this is not visible to the user…the echo is used within a client component trace, if one is turned on. To provide you with simple on-screen output, simple use the MSGBOX standard VBScript command. Once your script is ready, or at least starting to take shape, the next step is to put it on the UAG server. To do so, place it under <UAG Folder>\von\InternalSite\CustomUpdate. Now, you need to let UAG know that it is supposed to use it. To do this, create a text file with the following syntax:

g_scriptList("/InternalSite/CustomUpdate/<YourDetectionScript.vbs>") = false

Save the file under <UAG Path>\von\InternalSite\inc\CustomUpdate, and name it according to your trunk’s name and type, based on the following template:

<TrunkName><https:1/http:0>Detect.inc

For example, If you are creating this for an HTTP trunk named “publicportal”, name the file “publicportal0Detect.inc”.

Now that the files are all in place, you can activate your configuration, and test the script. Any MSGBOX command will pop-up on the client during the detection, and the resulting parameters will be reported to the session manager. You can open the session in the UAG Web Monitor, and go to the PARAMETERS page, and see the values reported by your script. Note that the default script also runs, so you will see the values reported by it, in addition to yours.

If your values are reported as expected, the next step is to create a custom endpoint policy that looks for these values and acts on them. Keep in mind that an endpoint policy is just a collection of values and Boolean operators – it’s not a real script. Such a policy is evaluated by UAG, and the variables in it are replaced by values collected from the endpoint. Once collected, the server evaluates the “total” value of the policy, and will allow the user access if they evaluate to a Boolean “1” (or True).

For example, let’s say you want to allow access only to computer who have Office 2007 installed. To do this, you might check if the file winword.exe exists. In a policy, this would look like this:

Results(“Office2007_installed”) = Whale.FileSystem.Exist (“c:\Program Files\Microsoft Office\Office12\WINWORD.EXE”)

Then, you would create a simple endpoint policy saying simply:

Then, assign that policy to an application, or to the trunk itself! You could also go further and check the version of the file, or look for certain keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0 to see other properties of office…it’s really up to you how deep you want to go into this.

Blog post written by Ben Ari

Regular Expression syntax to exclude values from a wildcard expression

MeirM [MSFT] — Fri, 20 May 2011 22:50:40 GMT

RegEx (Regular Expressions) is commonly used when configuring UAG portal applications. In addition, RegEx is also used when configuring application customizations such as AppWrap and SRA.

I recently worked with a customer that posed a fairly unique question. He wanted to know how to create a regular expression that would match the following:

Include any server in domain.com, excluding server02.domain.com

The Regular Expression that will accomplish this is as follows:

^(?:(?!server02).)*\.domain\.com

Explanation:

(?!server02) = Impossible to match ‘server02’

(?:(?!server02).) = ‘?:’ indicates not to create a backreference. ‘Dot’ indicates to match any single character.

^(?:(?!server02).)* = ‘Carat’ indicates to assert the position at the beginning of the string. ‘Asterisk’ indicates to match between zero and unlimited number of times.

\.domain\.com = “.domain.com”

Blog post written by Richard Barker

AppWrap and SRA

MeirM [MSFT] — Thu, 12 May 2011 21:57:05 GMT

The Application Wrapper (AppWrap) and SRA are two mechanisms UAG uses to dynamically rewrite the content of textual web data it processes. When UAG delivers a page to the client, one of the core UAG components known as “the filter” parses the content of the page, and in some circumstances, alters the content. This mechanism is mostly designed to allow better compatibility for application publishing, as certain applications were not designed to be published by UAG (or by any other reverse proxy, for that matter), and won’t work properly without certain changes. For example, when publishing SharePoint, UAG needs to perform certain manipulations to allow Office applications to open documents from the site properly. To this end, UAG inserts a line into one of SharePoint’s JavaScript files (core.js) that causes the browser to call the file sharepoint.asp (a specially crafted UAG code file):

dHtmlLoadScript(“/InternalSite/sharepoint.asp?site_name=portal&secure=1”);

For the AppWrap and SRA mechanisms to work, UAG comes with a set of XML files that contain instructions for them. The XMLs contain code that instructs UAG to look for certain file patterns (in HTTP requests as well as in the responses to them) and make certain changes to them, like, for instance, “Where you see the word ‘Foo’, change it to ‘Bar’”. UAG comes with a built-in set of 2 files (one for SRA and one for AppWrap), but the administrator can also create custom files in addition to them, to make his own changes. These changes can be used to address certain issues with the applications behavior when published through UAG, and also affect the look and feel of the application. For example, a UAG administrator may feel that when he publishes Outlook Web Access via UAG, he doesn’t want the user’s name to appear at the top of the screen.

To make this happen, the administrator will have to configure UAG to search for this text:

<span id="spnUserTileTxt" class="userTileTxt"> , and add an HTML tag like style=display:none; to hide it.

We’ll get to the how-to for this soon, but the point is, by manipulating the HTML, as well as HTTP headers, one can accomplish a lot!

In-difference?!?!

You might be wondering what is the difference between SRA and AppWrap? Why do we need two if they can both change content? The difference between them is the order in which things happen. When UAG retrieves a file from a back-end server, the 1^st thing that happens is the SRA engine processing the content. Next, the HAT engine signs the various URLs it locates, and then, the Application Wrapper performs additional changes, if such are required. If all we want to do is alter some static contents, then either of them can do the trick. If, however, we want our customization to handle URL-specific issues, it would be ideally handled by a custom SRA.

Here’s an example: We might find, in some circumstances that UAG is failing to sign some URL, because the URL is built using HTML tags that are non-standard, or built dynamically using a client-side script (for example, PeopleSoft software does this). When something like this happens, the script that builds the request may contain URL pieces that are unrecognizable. By using the SRA, we can replace the URLs in the script with something UAG can recognize, and then the HAT signature process can continue as normal.

How does it work?

As mentioned above, UAG comes with a pre-existing default set of files, which contain instructions for some of the built-in application templates, like CRM, OWA, SharePoint, Citrix and others. If you need to add other changes, you first need to decide whether you are going to use AppWrap or SRA. Some changes should be done in SRA – for example, if you are trying to fix an issue where an application’s links are not getting signed properly. Many changes can be done just as well with either mechanism.

Once decided, you need to compose an XML file with the proper “instructions”, and place the file on the UAG server. Once the file is placed in the right place, it takes effect immediately. The default files are created by UAG automatically in the following folder:

<UAG Path> \von\Conf\Websites\<Trunk_Name>\conf\

The configuration is separate for every trunk, so there is a separate set of XMLs for each trunk you may have. If you look at one of your trunks, you will find 2 files:

· WhlFiltSecureRemote_HTTP.xml or WhlFiltSecureRemote_HTTPS.xml, depending on whether the trunk is an HTTP or an HTTPS trunk. This is the configuration file for SRA

· WhlFiltAppWrap_HTTP.xml or WhlFiltAppWrap_HTTPS.xml, depending on whether the trunk is an HTTP or an HTTPS trunk. This is the configuration file for AppWrap

If you have a UAG server around, you can go ahead right now and examine the content of the files. You will find them to be quite lengthy, and possibly hard to understand…that’s perfectly normal! However, don’t be tempted to edit these files directly. These files are built from another source, so they may get overwritten and any changes you make may be lost. To support custom configuration, you need to create a folder named CustomUpdate under …\Websites\<Trunk Name>\conf, and place your custom files there. The server won’t explode if you edit the default files, but such an edit will be overwritten on your next configuration-activation. Also, such changes are unsupported.

Base 64 Encoding

Another thing to keep in mind is that since we use XML files to configure the Application Wrapper and SRA, we need to make sure that the contents of the data we are specifying doesn’t break the XML formatting. For example, the characters < and > are used by XML to specify opening and closing tags (more here). If our Search or Replace strings contain these characters, the whole thing may break apart (meaning that none of custom configuration will take effect). The solution to this is Base-64 encoding of the text. Base64 encoding is quite simple - It’s quite easy – just use some online encoding/decoding tools like this. Paste into it your string, and then copy-paste back the encoded text. You can also use the UAG Editor, which comes with UAG and has built-in functions for text editing. This editor is found here:

<UAG Path>\Common\Bin\editor.exe

To use it, simply select some text, and click on “To 64”:

Down into the mine shaft…

Here’s a typical custom AppWrap XML file:

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

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>SharePoint14aam</APPLICATION_TYPE>

<DATA_CHANGE>

<URL>SignOut\.aspx</URL>

<SAR>

<SEARCH>Function Activate</SEARCH>

<REPLACE>Function Deactivate</REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

As you can see, it has standard XML formatting, with nesting <> tags. It starts with a declaration of the type of file, and then starts a “manipulation” section. We specify the application type this applies to, and then, this section has a DataChange section (it could also have a Header Change section). The Data Change applies to the URL SignOut.aspx, and the \ behind the dot is not a speller…it’s a RegEx “escape” character, so that the dot will be treated literally. Later on comes a SAR (Search And Replace) section, which specifies the string to search for, and the string to replace it with. Then, all the sections are closed. Simple, huh?

The above example is a very simple one. In real life, there are a few more considerations. For example, when creating a custom file, it’s a very good idea to put in some comments as to what the change is for. This could be very important If the published application changes (which happens a lot!) and you need to revisit the customization, or if someone else needs to take ownership of the server. The syntax for comments is like this:

Another consideration is the URL specification. When specifying a URL, you can use the full URL for the target file, or just part of it using RegEx. It is recommended to specify the file as accurately as possible, and avoid a too-general wildcard (like .*\.aspx), so as to reduce the risk of the change applying to unintended files. When specifying URLs, remember that the characters . * ? + ( ) { } [ ] ^ $ \ are part of the RegEx command set, , so if you want them to be treated literally, you need to ‘escape’ them by adding a back-slash symbol before the character.

Normally, the URL search is case sensitive, so specifying SIGNOUT will not “find” a URL with the string signout, but you can add the case_sensitive tag to override this default. This is used like this:

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

Another thing to keep in mind is that you can perform several S&Rs on a single URL using a single clause by specifying additional SAR paragraphs like this:

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

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>GenericWebApp</APPLICATION_TYPE>

<DATA_CHANGE>

<URL>/hr/Editform\.aspx\?osver=6.*</URL>

<SAR>

<SEARCH>DHScript</SEARCH>

</SAR>

<SAR>

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

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

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

</MANIPULATION>

</APP_WRAP>

As you can see, the above example uses a similar syntax to completely remove parts of the HTML by simply using a blank REPLACE clause. Also, the 2^nd SAR in this example is for a complex text, I encoded it using Base64.

It is VERY important to remember that search-and-replace is a double-edged sword. When an S&R function is applied, it will perform the replace blindly, as long as the string or regex pattern configured in the SEARCH tag is matched against the HTTP data. This may inadvertently make changes to another section of the page or even to another page, causing undesired behavior. In certain cases, it may even corrupt data, if the change applies to code that is being sent back to the server (like SQL update queries, for example). One must be sure to plan the change very carefully, and make sure it will be applied only to what is relevant by limiting it to the appropriate application server and URL, and if possible, using detailed SEARCH parameters. Extensive testing of the change is also highly recommended, so that you don’t find out a week after rollout into production that it causes some other page to mess-up.

What else can AppWrap do?

AppWrap has several other options that are useful. For example, it can do a Header Change (which includes editing an existing header, deleting a header, or adding one). For example, an AppWrap can be used to remove or change the value of a cookie to something else, or alter the value of the referrer header to something other than it is normally. There are additional options, which I can’t cover here. If you want to learn more, have a look at the Advanced User Guide for IAG. For the most part, the syntax for UAG is almost identical. The guide can be found here.

Another thing AppWrap can do is change content based on dynamic variables. This is useful when you need to change a link to one that refers to UAG itself. Instead of actually putting in UAG’s URL, you can simply use the variable “WhlOwnURL”. This is a better design, as it’s more flexible and will work even if you change the server’s public URL, or if you need to apply the same change to a lab server and a production server. Other variables that UAG supports are:

· WhlSessionTimeout

· WhlLogoffURL

· WhlScheduledLogoffTimer

· WhlSiteName

· WhlSecure

You can read more about these variables on page 229 of the Advanced User Guide that I mentioned above. Here’s an example of the use of WhlOwnURL:

<DATA_CHANGE>

<URL case_sensitive="false">/exchange/.*?Cmd=navbar</URL>

<SEARCH>vw_navbar.js"></script></SEARCH>

<REPLACE>vw_navbar.js"></script><script language="JavaScript" src="WhlOwnURLscripts/CacheClean.js"></script>

</SAR>

</DATA_CHANGE>

This example is taken from the UAG default AppWrap template. This section applies to publishing OWA 2003, and its purpose is to hide the OWA log off button and to add some JavaScript related to UAG session termination. To make the read easier, I’ve decoded the text, which is Base64 encoded in the original file. You can see how it refers to several variables – can you guess what they mean?

Moving forward…SRA!

A custom SRA file would have a layout that’s quite similar to an AppWrap file. Here’s one, for example:

<DATA_CHANGE>

<APPLICATION_TYPE>SharePoint14aam</APPLICATION_TYPE>

<URL>

<NAME>drawshape\.aspx</NAME>

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

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

</URL>

</APPLICATION>

</DATA_CHANGE>

</WHLFILTSECUREREMOTE>

SRA does not allow the use of variables, but it can be configured to match a specific server and port, which AppWrap cannot do. Here are a few examples:

<DATA_CHANGE>

<SERVER_NAME mask="255.255.255.0">192\.168\.1\.75</SERVER_NAME>

<URL>

<SEARCH encoding="base64">PGhlYWQ+</SEARCH>

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

</URL>

</SERVER>

</DATA_CHANGE>

<DATA_CHANGE>

<SERVER_NAME>exchange01</SERVER_NAME>

<URL>

<SEARCH encoding="base64">PGhlYWQ+</SEARCH>

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

</URL>

</SERVER>

</DATA_CHANGE>

<DATA_CHANGE>

<APPLICATION_TYPE>GenericWebApp</APPLICATION_TYPE>

<URL>

<NAME>/mail/.*/Inbox/.*\.EML\?cmd=preview</NAME>

<SEARCH encoding="base64">PGhlYWQ+</SEARCH>

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

</URL>

</APPLICATION>

</DATA_CHANGE>

In the 1st example above, we are matching the server by its IP, and in the 2^nd, by its hostname. Note that this refers to the INTERNAL name of the server (which is what you would define in the “Web Servers” tab of the application on UAG):

As you may have deduced from the example, the MASK tag in the SERVER_NAME tag can be omitted, and the PORT tag can be omitted as well. As with AppWrap, multiple SERVER_NAME paragraphs can be nested inside a SERVER paragraph and multiple APPLICATION_TYPE paragraphs can be nested inside an APPLICATION paragraph. Also, multiple URL paragraphs can be nested inside the APPLICATION_TYPE and multiple URL paragraphs can be nested inside a SERVER_NAME paragraph.

Adding a HAT signature

A typical troubleshooting scenario is one in which links are not being signed for some reason. This can happen if the links are built by some client side JavaScript, out of URL pieces. For example:

var hrapp_web_root = 'http';

var IntServer_url = ‘fileservny01’;

var hrapp_js_root = '/vrdf/js';

var hrapp_jsp_root = '/vrdf/jsp/hrapp';

if (mode == secure) {

hrapp_web_root == hrapp_web_root+'s'

}

var sTarget = hrapp_web_root+'://'+ var IntServer_url + var hrapp_js_root

In the above, the resulting URL could be either “http://fileservny01/vrdf/js” or “https://fileservny01/vrdf/js”, but the text page doesn’t actually contain any URL strings that UAG can recognize. To fix it, we would need to convert the resulting string to one that has the HAT signature. For example, https://fileservny01/vrdf/js would have to become:

https://uag.createhive.com/uniquesig977dbf8e31f3e11905690532814f23eaedf4b8fa30977329b63b23e65d8cbc 8868 fb5af9e91fd3a1c405dc86ecaed7a1/uniquesig0/vrdf/js

To make this happen, we would have to create an AppWrap that replaces the URL pieces. We would need to replace line no. 2 in the above JavaScript to something like this:

var IntServer_url = ‘uag.createhive.com/uniquesig977dbf8e31f3e11905690532814f23eaedf4b8fa30977329b63b23e65d8cbc8868 fb5af9e91fd3a1c405dc86ecaed7a1/uniquesig0’;

This is not hard, and you already know what you need to make this happen. However, we consider putting in a HAT path directly to not be best practice. Instead, we have an SRA method which can be used to add the signature automatically. Here's the syntax:

<DATA_CHANGE>

<SERVER_NAME>formserver\.createhive\.local</SERVER_NAME>

<URL>

<ADD_SIGNATURE encoding="" location="before">test/id/user</ADD_SIGNATURE>

<ADD_SIGNATURE location="after" mode="regex">ows_FileRef</ADD_SIGNATURE>

</URL>

</SERVER>

</DATA_CHANGE>

The example above does not apply to the JavaScript I included earlier, but you can see from it that you can use the location tag to indicate that the signature can be added either BEFORE or AFTER a certain text. The search is done on static text by default, but can also be done using RegEx if you specify the mode as such, as in the 2^nd ADD_SIGNATURE tag above. As usual, encoding to Base64 is often needful. The same URL syntax can be nested inside an APPLICATION tag, instead of SERVER. If so, the application type must be specified as before. It’s important to note that the signature that is added is in this format:

uniquesig977dbf8e31f3e11905690532814f23eaedf4b8fa30977329b63b23e65d8cbc8868fb5af9e91fd3a1c405dc86ecaed7a1/uniquesig0/

It does not include the public host name of the UAG portal, but if the URL is relative, it will be automatically applied by the browser. However, if the link that we want to sign is relative as well, and starts with a slash, we should adjust the location appropriately. For example, if the targeted code is something like:

<script>function serverset(){URLpart=’/ipage/customer/order/cart/or4020AddItem.action’;

And we want to sign the “URLpart” piece, we would either insert the signature after URLpart="/ or before ipage/customer/order/cart/or4020AddItem.action

How to find the application type

If the APPLICATION method is chosen, rather than SERVER, you must locate the application type that you wish to match to. If this is a custom app you have created, then you have had to choose the application type, and you can see it in the application list on UAG:

If, however, you want to apply your code to one of the built-in application types, you will need to find the ID manually. To do this, open the applications properties from the trunk's application list. Note the application's name (see screenshot below).

Now, open the file <UAG Path>\von\Conf\WizardDefaults\WizardDefaultParam.ini with a text editor of your choice, and use the FIND function to locate that text. When you have found it, look above it, for the application type in square brackets:

What else can SRA do?

An important thing to remember about SRA is that it is THE brains behind the link signing that UAG does, and even though it sometimes misses some links, it is possible to "teach" it to do it better. The default SRA configuration files (<UAG Path>\von\Conf\SRATemplates\WhlFiltSecureRemote_HTTP.xml and WhlFiltSecureRemote_HTTPS.xml) have a long list of tags that instruct the engine how to detect links, so that they can be signed. If a link is missed by the engine, it may be possible to extend the list of tags so that the engine will detect it by default, rather than include a search-and-replace fix for a specific link. Customizing the default parsers is beyond the scope of this guide, and will be discussed another time.

Conflicts and combinations

When creating a custom AppWrap or SRA file, one must keep in mind that UAG still has to use the default built-in XML files, and we need to be careful about creating a conflicting set of files. Sometimes, we might want to intentionally override the default template, but at other times, we need to be careful, otherwise, the custom file may block built-in functionality that is important.

One common mistake is to define an extremely wide range of URLs by using something along the lines of “<NAME>.*</NAME> in the URL section. Something like this will actually override ALL other AppWrap or SRA settings for the same application-type or server-name defined anywhere else. Special care needs to be taken when working on one of the built-in application types. For example, doing this on a SharePoint or OWA application will cause huge problems. If you do need to use AppWrap or SRA to make changes to an application that has some SRA/AppWrap functionality in the default files, and you need to change the same URLs in the default template, the right way to go is to COPY the default settings into the custom file, and adjust (or add to) them in it. There’s no simple way to do this, so be prepared for some trial and error. You might also need to combine two sets of instructions. For example, you might need to combine the default set, and your custom instructions, or one customization with another. Look at the following example (AppWrap):

<MANIPULATION_PER_APPLICATION>

<APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE>

<DATA_CHANGE>

<SEARCH encoding="base64">cGFyZW50LmQmFzZSArICI/Q21kP </SEARCH>

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

</SAR>

</DATA_CHANGE>

<DATA_CHANGE>

<URL case_sensitive="false">/exchange/.*/(inbox/?|calendarcmd=rules|\?cmd=options).*</URL>

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

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

</SAR>

</DATA_CHANGE>

<DATA_CHANGE>

<URL case_sensitive="false">/exchange/.*?Cmd=navbar</URL>

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

<REPLACE encoding="base64">+DQo8c2NyaB0IiBzcmM9Ildob==</REPLACE>

</SAR>

<SAR>

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

<REPLACE encoding="base64">+Dldob==</REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION_PER_APPLICATION>

The above example is taken from the default AppWrap file, though I’ve cut most of the S&R strings short to make it more readable (so the example is not ‘really real’…). It demonstrates how, when we want a manipulation section to address separate URLs, it has to have separate “data change” sections, each addressing its own URL. If we want to do multiple search-and-replace actions, this is OK too, as long as they are in separate SAR sections, as shown in the 3^rd data change section above.

Further Reading:

The official UAG documentation contains some information about using the application wrapper:

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

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

If you’d like more details, samples and information about the SRA, you can find it in the original IAG Advanced User Guide, pages 289-313 and pages 219-254. This guide is very extensive and detailed, and even though it was written for IAG, most of the content applies to UAG, except some minor changes (http://blogs.technet.com/b/edgeaccessblog/archive/2009/11/17/appwrap-in-uag-what-s-new.aspx). To download the IAG Advanced User Guide, click here.

Blog post written by Ben Ari and Ran Dolev

Firewall settings could not be configured?

MeirM [MSFT] — Wed, 04 May 2011 22:50:21 GMT

When you try to activate UAG, you might find yourself staring at an error saying “firewall settings could not be configured, unknown error 0xc00403c4”

This is not a very common situation, but it may happen if you have made changes or additions to the firewall rules on TMG that’s on the UAG server. As you may or may not know, making changes to the TMG configuration on a UAG server is not only unsupported (except some specific scenarios), but also dangerous. Normally, UAG is in charge of being the configuration king, and when you perform a configuration activation, it pushes certain settings into the TMG configuration. Interfering with this process is hazardous, and can lead to disappointments such as the one above, or even worse. How? Well, the TMG is there to serve as a security layer for your protection, and making changes or additions to the rules may cause a conflict that could lead to inoperability of the server, or a security exposure. The above example is exactly this kind of thing. When you make such manual changes to the TMG configuration, it may prevent it from accepting the settings that UAG tries to create, and can leave you with a server that is completely unresponsive to client requests.

If you do run into the error above, start by making sure no one made any changes to the configuration, and if some were made, reverse them. In some circumstances, such a chance may work for a while, and show its ugly head much later, when you create a new trunk or make some other significant configuration change.

If you are wondering what specific scenarios I was referring to earlier, these are documented here: http://technet.microsoft.com/en-us/library/ee522953.aspx. Additionally, if working on a support case, a Microsoft representative may guide you to make manual changes, which is perfectly fine, of course.

One scenario for which we have seen users make changes to their Config is when trying to provide access to or from external servers. For example, to allow themselves to RDP into the UAG server from a corporate machine, such a change would be required. However, there’s a proper and supported way to do this:

1. Open the TMG console, and go to Firewall Policy

2. On the Toolbox tab, click Network Objects.

3. Expand Computer Sets, and then double-click Remote Management Computers:

4. On the Remote Management Computers Properties dialog box, click Add, and then select Computer.

5. On the New Computer Rule Element dialog box, type the name of the computer, in Computer IP Address, enter the IP address of the remote computer, and then in the Description box, provide an optional description. On the New Computer Rule Element dialog box, click OK:

6. On the Remote Management Computers Properties dialog box, click OK.

7. On the Apply Changes bar, click the Apply button, and then on the Saving Configuration Changes dialog box, click OK.

Another scenario which we have seen is when the UAG computer needs to run some software that needs to connect to some backend server. For example, an Anti Virus or backup agent. This is not as simple as it looks, as the UAG supportability guidelines also dictate that no additional software should be installed on the UAG server, to prevent potential conflict with the UAG or TMG software. This mostly applies to service software, while Microsoft is more forgiving towards protection software like an Anti Virus. There are several other considerations for using AntiVirus software on a UAG server, and these are discussed here: http://technet.microsoft.com/en-us/library/cc707727.aspx. However, the point here is that if a certain piece of software requires access to some other computer, the right way to do it is not by manually creating a TMG rule. Instead, create an app!

The idea here is to configure a “ghost” application that will make UAG configure TMG to allow the traffic we need. The application will not be used by anyone, and we can even make it hidden. All it will do is specify servers and ports that UAG needs to push into TMG. Here’s how:

1. On the UAG portal, create a new application. If you have more than one trunk, it can be done on any of them – it does not matter.

2. Select “Client/Server and legacy” group, select “Generic Client Application”. You may also select “Generic Client Application(Multiple Servers)” if you need to add multiple servers, or multiple ports.

3. Give the application a descriptive name to remind yourself what it is for

4. Choose any access policy – it doesn’t matter, as it won’t be used by users anyway.

5. In step 4 of the wizard, specify the IP or name of the servers that need to be accessible:

6. On step 5 of the wizard, uncheck the option to show the app on the portal:

7. Finish the wizard, and activate the configuration.

As part of the activation process, UAG will create an access rule to allow access to the server(s) and port(s) specified in step 4, and your problem should be over!

Blog post by Ben Ari

Creating custom icons for applications

MeirM [MSFT] — Wed, 06 Apr 2011 21:21:37 GMT

Several customers have asked for help in creating their own custom application icons. This is a rather simple process that only requires a simple paint program and some understanding of the CustomUpdate process and appicon structure.

UAG requires 4 icons for each application:

1. A regular (large) icon

2. A nav-bar (small) icon

3. A “disabled” regular icon

4. A “disabled” small icon

UAG comes pre-configured with many icons, covering all the built-in templates, but you can create your own sets. This can be done with something like Paint.NET, or a more advanced application, if you have reasonable control over one. The icons you need to create should be 88x50 pixels for the large icons, and 15x15 pixels for the small icons. The UAG default icons for “disabled” apps (apps for which the user has no access) are “grayed out”, but you are free to create any shape or form you want. For example, you might prefer an icon with a large X on it, or some custom text – anything goes, really.

To configure an application to use a custom icon, you need to adjust the “Icon URL” setting in the application’s Portal Link tab:

On the Icon URL setting, you specify the name of the primary (Active application with a large icon) file, including the relative path that starts with the image folder, and the CustomUpdate folder name (see example in the screenshot above). UAG will look for the other 3 icons based on the following naming convention:

1. A regular (large) icon - <name>.gif

2. A nav-bar (small) icon - <name>_dis.gif

3. A “disabled” regular icon - <name>_icon.gif

4. A “disabled” small icon - <name>_icon_dis.gif

The actual image-size is not critical, because UAG will display the icon even if it’s not the right size. It will, however, show it at the standard size and shape, so if you create different files, they may be appear distorted

As with all UAG customizations, the custom files should be located in the CustomUpdate folder. The full location is:

C:\program files\Microsoft Forefront Unified Access Gateway\Von\PortalHomePage\Images\AppIcons\CustomUpdate

Once you put your files in the CustomUpdate folder, adjust the Icon URL setting and activate the configuration, the application should show the image right away.

If this is not working properly, you need to check the URL of the icon that UAG is trying to load. This is not that simple, as the right-click functionality on the portal is disabled normally, so you can’t just right-click on the dead icon and see its properties. Instead, you can use a tool such as HTTPWatch or Fiddler to view the page source and see:

The ContentFrame.aspx page is where the large icons are at, and the MainFrame.aspx page is where the small icons are at. You may discover that you have made a typo in the file name or path. Another possibility is that the image itself is not fully compatible to the file-format standard, and IE just can’t show it. This is also visible in the HTTPWatch trace – the “result” column will show a 200 for an image that was downloaded successfully (meaning IE got it…but can’t show it) and a 404 for an image that was not found on the server for some reason.

The last tip for creating icons is that you can use PNG or GIF files for this task, and these also support transparency. The small icons are displayed against a gray background, while the large ones are on a white page. You might want to consider creating a transparent background for your icon images, to make the appearance look best. Not all paint programs actually support this, but it’s worth looking into!

Blog post written by Ben Ari

No place like HOD

MeirM [MSFT] — Tue, 15 Mar 2011 17:57:13 GMT

IBM’s Host On Demand (HOD) application is a fantastic solution, providing access to IBM mainframe servers through a browser. It’s basically a Terminal emulation client written in java, allowing it to be embedded into the browser, and allowing it to be published on a company’s external website via technologies like UAG’s SSL-VPN publishing.

Back in the days of IAG, HOD was quite popular, and so IAG had a special template for it. When UAG was being developed, the need for HOD was on the decline, and so the template for it was removed. This doesn’t mean, though, that it cannot be used! On the contrary…with the proper configuration, it can be used with ease!

The trick is to realize that HOD is what we, in the UAG world, like to call ‘a browser embedded application’. A B.E.A. is a fancy term for an application that is not web-based (i.e., not communicating with its server using the HTTP or HTTPS protocols), but it’s launched from within an HTTP or HTTPS session. Many JAVA, Flash, Silver light and Active-X based applications are like that, and so is HOD. There are even some executable apps that are like that too!

The way a B.E.A. application works is by being offered to the user via a web page. The user visits the page, which has an embedded “call” for the application. When the page loads in the browser, it instructs the computer to launch the application using its framework, and then the application needs to communicate with its server using some non-HTTP or HTTPS communication channel. That framework would typically be installed on the client’s computer, somehow. Active-X, for example, is already baked into every version of windows out there. Flash, Silver light and Java would typically require the user to install those frameworks (The Flash player from Adobe’s website, Java from Oracle’s site, and Silver light from Microsoft’s).

Just the fact that there’s a flash, Silver light, active-X or Java application on the page doesn’t mean it’s a B.E.A. application. Such an application may be able to communicate with its server using HTTP or HTTPS, and if so, may work using any regular web-based template in UAG. However, some apps use other protocols. For example, another B.E.A. is Citrix, which communicates with its backend server using their own protocol on ports 1494, 2598 and 3389.

When a B.E.A. application is published on UAG, it is configured to launch an SSL-VPN tunnel, and then launch the client from the browser. The client can then use the SSL-VPN tunnel to communicate with its backend server. To publish a B.E.A. application on UAG, all you have to do is figure out the names of the servers it is supposed to communicate with, and the ports it needs to use. Then, run the UAG application wizard, and from the application template menu, select “Generic Browser-Embedded Application (Multiple Servers)”:

On step 5 of the wizard, you need to configure the properties of the WEB server. This is the server which hosts the web page with the links to the application. Often, there would be only one web server that hosts both the web page, and the actual application, but it’s not always the case. Keep in mind, though, that the HTTP PORTS are only for the web page, so this would be usually either HTTP or HTTPS. This is not where you would specify the higher ports!

Step 7 of the wizard is where the magic happens. The servers and ports listed there define, for the SSL-VPN tunnel, to which servers on the inside traffic needs to be forwarded. Here you might specify one or more servers, and one or more ports (separated by commas). As the administrator, you may not always be aware of ALL the servers that are involved, so make sure you do your research with the application’s owner. It’s sensitive – missing a single server or port could ruin the party. Keep in mind, though, that the HOD Config may differ from server to server, and that you can always go back and add something, if you forgot or got it wrong:

Once done and activated, launching the new application is supposed to launch the UAG SSL-VPN tunnel on the client, and display the notice “Ready to launch application”. At this point, you are supposed to see the SSL-VPN blue-yellow arrows on your client’s systray, and the HOD application should launch inside the Java window on the browser. If the SSL-VPN tunnel is not opening at all, then it means there’s something wrong with the client components on this specific client, so the 1^st step would be to check another client, preferably a “clean” one (without older versions of the components, or a computer that hasn’t been tortured too-much). If the tunnel is launching, but the HOD app doesn��t launch, troubleshoot your Java installation. There are multiple versions of the Java client, and some are known to be more challenging to get working than others. If the HOD app is launching, but unable to connect to its server, then it means the tunnel is not permitting access to the appropriate server or port. This may be tricky to troubleshoot, but a 1^st step would be to use something like Network Monitor on a regular, internal client, and see if the application may be using other ports, or calling other server names.

Post written by Ben Ari

Cheers to Thomas O. for your help with this!

Microsoft Forefront UAG 2010 Administrator's Handbook is now available in print

MeirM [MSFT] — Mon, 28 Feb 2011 23:07:37 GMT

We are glad to inform you that the Microsoft Forefront UAG 2010 Administrator's Handbook, published by PACKT publishing is now available in print. The book was written by Ran Dolev and Erez Ben-Ari (also known as “Ben Ben”) from the UAG product support team. It covers UAG publishing scenarios, DirectAccess and troubleshooting, which makes it the most complete self-study and reference resource for UAG available on the market.

The book is available for order from Amazon, or from the publisher directly, and is available as a hard-copy, or e-book.

Forwarding on the 6to4 network interface cannot be enabled

MeirM [MSFT] — Fri, 28 Jan 2011 21:07:54 GMT

An error you might run into when activating a DirectAccess configuration is the dreadful “Forwarding on the 6to4 network interface cannot be enabled”:

This often happens after you rebuild a server, and try to restore a configuration from backup, and is typically caused because of a duplicate 6to4 interface.

The first step of resolving this is to enable the interface manually, which is done this way:

1. Find the name of your 6to4 adapter by running the command netsh int ipv6 show int. This would often be “6to4 adapter”

2. Enable forwarding by running the command netsh int ipv6 set int <NAME> forwarding=enabled where <NAME> is what you found in step 1

Now, try activating DA again from the UAG console. You would probably be disappointed to see it fail again. If so, the reason is probably because the computer has duplicate 6to4 adapters, confusing the server. If so, you can easily fix this by removing the interfaces from the Device Manager:

1. Open Device Manager

2. Click View and select “View Hidden Devices”

3. Notice the two 6to4 adapters? There’s your problem. Remove both of them by right-clicking and selecting “uninstall”.

4. Close the device manager, and reboot the UAG server.

5. After a reboot, the 6to4 adapter will be re-added, but only once, so you should be good to go.

6. Activate the UAG configuration again, and this time, it should be fine!

Blog post written by Ben Ari

UAG and SharePoint mobile access

MeirM [MSFT] — Tue, 18 Jan 2011 21:59:56 GMT

A nice feature of SharePoint is SharePoint Mobile Access, which allows you to access SharePoint sites on a mobile phone, without having to cope with the busy SharePoint web interface on the phone’s small screen. This is a built-in feature of UAG, as well as Windows Mobile. Configuring this on UAG is not that difficult, but many users are not familiar with how to actually use it on the phone itself.

Let’s start with the UAG side. It’s pretty straightforward, and you might have guessed it yourself, but just to be sure we are all on the same page, this is how it’s done. To configure the UAG portal to support the mobile phone access, you need to enable the mobile browser on your published SharePoint application (on the UAG). To do so, open the application’s properties, and go to the Portal Link page. Enable the settings like this:

Simple, right? Now here comes the hard part…viewing this on the phone. It’s not REALLY hard, but since that part will be performed by your users, it may be a challenge to help all of them configure this correctly. The procedure is as follows:

1. Open the phones start menu, and go to the Office application:

2. On the office application, go to the SharePoint page, and tap on All:

3. On the All page, expand the bottom tab with the 3-dot button, and tap on Settings:

4. On the settings page, tap on UAG server :

5. On the UAG server page, fill in the UAG server details and tap Save. The “UAG Server Address” is the name of the UAG Trunk on which you publish the SharePoint server, including the protocol prefix (not the public hostname of the SharePoint application itself). For example: “https://uag.contoso.com”. Make sure you feed in your username in the domain\username format:

After savings the settings, go back, and tap on “Open URL”, and type in the internal URL of your SharePoint server (the same one you would type if you were working on your computer in the office). Note that if the SharePoint is set to accept only HTTPS connection, you need to type that as part of the URL as well. The phone will open the URL through the UAG server you have configured, and you will be presented with your documents, which you can now open, edit and save!

Some more info about mobile phones and SharePoint

One thing several users have been asking themselves it is possible to access a SharePoint server without a UAG (ie: a SharePoint that’s directly on the internet, or published using a simple firewall). Unfortunately, the answer is no. The WP7 application is designed to be able to authenticate to a SharePoint only through a UAG server, and if you attempt to access a SharePoint directly, you will receive a message titled “Can’t open” saying “SharePoint doesn’t support this authentication scheme”. The message suggests opening the site in the browser, which is a great idea. In fact, SharePoint even has a nice mobile feature that you may not be aware of. If you append the parameter ?mobile=1 to a SharePoint URL, it will be displayed in a compact form that’s bandwidth-conservative and screen-size optimized for a mobile phone:

Blog post written by Ben Ari

Hiding the UAG portal bar

MeirM [MSFT] — Tue, 04 Jan 2011 20:43:15 GMT

The UAG portal is designed to let you publish multiple applications using a single public hostname, but many customers need UAG to publish only a single application, or simply don’t want to have the portal visible to their users, and have the users redirected to a specific application immediately after logon. The UAG User interface offers this option in a way that’s easy to see – you select an Initial Internal Application that is other than “Portal”:

Often times, the purpose of using this option is to present the user with an experience that hides UAG as much as possible, and for that, many users will also check-off the option “Display home page within portal frame”:

With this option set, the UAG interface is pretty-much tucked away and concealed, but this has a side effect that needs to be kept in mind. The UAG toolbar isn’t just for looks – it also runs some important scripts that affect the security of the site. For example, it is in charge of showing a notification that the session is about to time-out for inactivity. With it being hidden, the user may not become aware that his session is about to expire, and will only find out when he clicks a link and gets redirected to the login page.

In some circumstances, the result could be even more awkward. For example, if the published app uses frames, then action done in one frame may not affect the others, and so after a session expiry, one frame may remain with “old” content, while the user clicks a link in another frame and gets the UAG login page.

Before I go on and tell you how to get around that, it’s important to realize that hiding the portal frame is not the only way to get rid of it. UAG also supports “application-specific hostname” applications, sometimes referred to as “AAM-Like” applications. The way this works is by having you, the administrator; select a specific public name for one of the applications, and mapping it in DNS to resolve to the UAG Trunk’s public IP. For example, the portal may be published on “https://uag.contoso.com”, with the application published as “https://mail.contoso.com”. You need to configure your DNS to resolve these two names to the same IP, and if your UAG trunk is an HTTPS Trunk, then it’s certificate has to be a wildcard certificate (*.contoso.com) or a SAN certificate.

The application itself needs to be configured accordingly. If this is a generic web application, you need to use the “Other Web App(Application-specific hostname)” template, which has a special setting for you to let UAG know which public hostname this application will use:

When this is done, this is how it works:

As the user types https://mail.contoso.com in his browser, it resolves to the UAG’s external IP, and the request is received by the UAG. However, the request also includes the host-header, which tells UAG that the request was for that specific URL, and not to the portal hostname.

UAG uses the host-header to search it’s list of configured applications to find which one has that configuration, and will then retrieve data from that server (only after completing the login process, though, of course).

For some of the application template, this mechanism is mandatory. For example, CWA publishing and SharePoint publishing require that to be configured this way. You still can access those applications via the UAG portal, but if you look closely, these links actually point to the public hostname you defined. This is really nice, because you have the two options for the price of one – you can let your users access the application via the portal (by clicking on an app link), or directly, by typing-in the public URL. Naturally, they can also go to it from their Favorites folder or from a link that has been emailed to them etc)

Back to hiding the portal frame

As I said, just setting the portal frame to be off has some downsides, but there is another way to get this done. UAG uses CSS to control the way the portal frame looks, and it’s fairly easy to customize it to hide the frame without actually disabling it. This is discussed in the UAG Customization guide, alongside other ways to affect the appearance of the portal. The file in question is called Office.css, and it’s located at <UAG Folder>\Von\PortalHomePage\App_Themes\Office. As is always the case with UAG, you should not edit the original file. To make changes, copy the file to the <UAG Folder>\Von\PortalHomePage\App_Themes\CustomUpdate\Office folder, and then edit the file in CustomUpdate. Once you make a change to the file and save it, the change is applied immediately, so there’s no need to re-activate the configuration on UAG or to log-off/log-on again on the client.

You can make any changes to the CSS style sheet that suits your taste. For example, the style “display:none;” makes an element hidden from view, and changing the position and size styles (top, bottom, left, width, height etc) affects their position on the page. Note that setting the div#topStrip and div#toolbar (the frame is actually comprised of two separate ribbons) to hidden will just turn the top area of the screen to a clean white, but the app will still show-up in the area below it. To make the app stick to the top, you also need to change the location of the div#content element from Top:85px; to Top:0px;. You could move stuff around and even integrate your own unique elements to get your own company’s look-and-feel.

To make the entire frame invisible, you need to hide the following elements, and then move the content piece up, as noted earlier:

· div#topStrip

· div#toolbar

· div#footer

· .contentLeftSideBarCell

· .topLeftMarginGradient

· .topRightMarginGradient

· .bottomLeftMarginGradient

· .bottomRightMarginGradient

With these changes, the only thing you will see after logging in is the application list, or the application you have set as the initial app:

Blog post written by Ben Ari

Publishing Office Communication Server and Communicator Web Access with UAG

MeirM [MSFT] — Wed, 29 Dec 2010 23:59:48 GMT

Publishing Office Communication Server (OCS) and Communicator Web Access (CWA) with UAG has been a source of confusion for some UAG customers, mostly because these products offer a wide range of functionality. Some of this is pretty simple to configure, and some takes more planning.

When planning OCS publishing with UAG, one must take into consideration the fact that OCS has many features, functions and roles. Not all of them were planned with publishing in-mind, and UAG was not designed to publish all the features either. Essentially, UAG includes a special template for Communicator Web Access (CWA) 2007, and for other features, UAG does not include built-in functionality, and something “else” needs to be used.

Virtually any firewall product in the market can be used to publish internal servers to the outside world. Some companies may refer to this as “port forwarding” or “Reverse-proxying”, or even simply as “routing”. At Microsoft, we divide this into sort of functionality into two categories. The 1^st is “Web publishing”, in which an edge device gives computers on the internet access to web servers inside the organizational network. The 2^nd is “Server publishing”, in which the access is to services that are not necessarily web services (for example, RDP access). The difference is that web services are a narrow type of service, which is very clearly defined. This clear definition allows us to offer additional features that go beyond just moving the packets from one “side” to the other. For example, with Web Publishing, we can do more advanced content inspection, and can block certain file-types from being transferred.

If you purchased UAG to publish certain applications, good chance you’d prefer not to purchase any additional devices to publish the non-web OCS features, and the good news is that UAG does, in fact, include something else…TMG! If you read your documentation carefully or ever spoken to Microsoft Customer Support, you are probably aware that trying to use the UAG server for “other” things is not supported. You’re not supposed to tack-on an additional website on the IIS that’s on UAG to publish your cafeteria’s lunch menu, or use the SQL that’s there to store your inventory database. We do, however, allow for a certain, limited list of things to be done with TMG, as stated here in the support boundaries for uag (http://technet.microsoft.com/en-us/library/ee522953.aspx). This list includes publishing OCS features other than CWA.

When you publish something with TMG, you select whether you want to use Web Publishing or Server publishing by the type of task you select in the task list. There are actually some more variations for types of publishing, but for our purposes, the “Publish Non-Web Server” is the relevant one for OCS’s features. Using this wizard will allow you to specify which ports you need to publish, which depends on the type of service you need to publish. For example, you may need to publish port 5063 for incoming SIP listening requests or port 8057 for direct PSOM connections from Live Meeting clients.

I will not cover this in high detail here, as this blog is about UAG, but you can read more about server publishing in one of many books that are available about TMG, such as this one. For more information about ports used by OCS, refer to this article.

To publish CWA itself using UAG, what you need to know is that CWA needs to be published as a non-HAT application (a.k.a AAM-Like application). If you are not familiar with HAT and what it does, you might want to take a peek at this blog post. Like SharePoint, CWA cannot be published with the HAT mechanism, and requires its own public hostname, which brings the following considerations into play:

1. The public hostname needs to be based on the same public domain you are using for your UAG trunk. For example, if your trunk is published as https://uag.contoso.com, then you need to use something like https://*.contoso.com for CWA.

2. If your UAG trunk is an HTTPS trunk, it has to have a certificate, and that certificate needs to certify both the trunk’s hostname and the CWA’s. Most UAG customers use a wildcard certificate for this, and others prefer a more economic SAN certificate. I should mention that wildcard certs don’t have to cost an arm and a leg. Some websites like http://www.sslcatacombnetworking.com and http://www.rapidssl.com offer them for as low as $199 a year.

3. Both hostnames need to be publicly resolvable to the UAG trunk’s external IP. This is not absolutely mandatory, as you can use static HOSTS file entries on your client computer, but if your intended audience is the general public, setting up the DNS correctly is very important.

4. The authentication settings on the CWA server need to be adjusted to allow UAG to perform Single-Sign-On. With UAG, you need to publish the “External” CWA site, and use custom authentication, as described in the lab guide http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=0e21123a-8452-4b25-8cde-57f750cd7803

So, the 1^st step is to choose the name that you want to use. The 2^nd is changing your certificate, if you are using an HTTPS trunk and your current cert is not a SAN or Wildcard cert. The 3^rd step is to add the appropriate host name to your domain’s public DNS server. The 4^th step is to adjust the CWA site settings, or re-publish it according to the specifics in the above-mentioned guide. Once this is done, you can start the UAG wizard.

On the UAG application wizard, the key element is setting the public host name in step 5 of the wizard:

Setting the internal website is also important, because that tells UAG with which internal server it talks to. That server has to be resolvable and reachable on the appropriate ports. This part is no different than publishing other applications, but some users are iffy about it still. In case the publishing does not work, one of the first troubleshooting steps would be to try to access the server directly from the UAG server (open a browser on the UAG server, and browse to http://CWA01/quicksignin, in our case). If it does not work from UAG, it cannot work through UAG.

Blog Post written by Ben Ari