SymptomAdministrators require granular access control for their Secure Socket Tunneling Protocol (SSTP) virtual private network (VPN) clients. However, configuring SSTP on UAG creates a single access rule that gives VPN client’s access to the whole Internal Network.
According to the following text from http://technet.microsoft.com/en-us/library/ee522953.aspx, it is supported to use the Threat Management Gateway (TMG) console to create rules that enable granular access control for SSTP VPN Access:
"Creating access rules using the Forefront TMG Management console, for the purpose of limiting users, groups, and networks for granular access when deploying Forefront UAG for VPN remote network access."
However, when administrators create access rules to limit user access, these rules are removed or moved to the bottom of the access policy after UAG activation. This means that the default rule takes precedence and the configured granular control is lost.
CauseThis issues is caused by a limitation in the design of the integration between UAG and the dynamically generated rules that are deployed to TMG during UAG activation.
ResolutionManual modification of TMG rules to support granular access control as described on TechNet is depreciated (and is no longer supported after the installation of UAG Update 2) in favor of explicit support of granular access control in the UAG Management console.
UAG administrators can now explicitly enable access to particular internal network addresses to SSTP VPN users who are members of particular Active Directory groups. UAG administrators should use the new
User Groups tab of the SSL Network Tunneling Configuration dialog box to define granular IP VPN access policy which consists of a set of access rules. Every rule defines a set of internal network IP addresses and IP address ranges that members of a particular Active Directory group can access while connected to SSTP VPN.
Issue 2
SymptomMicrosoft Virtual Desktop Infrastructure (VDI) support in UAG is not fully implemented.
CauseBecause of a misleading UAG UI, problematic configurations and an inability to support multi-authorization in different resources during implementation prevent VDI from working correctly.
ResolutionWe have made a design change to update the UAG UI and support the Personal Desktop scenario of VDI with a more robust implementation. The Pooled Desktop scenario of VDI was not implemented and may be implemented in a future update of UAG.
Issue 3
SymptomThe UAG Client Component for SSL Application Tunneling (Socket Forwarder) is not supported on 64-bit version of Windows 7 and 64-bit version of Windows Vista.
CauseThis is the designed behavior of the UAG client components before the release of UAG Update 2.
ResolutionWe have made a design change to address the following scenario:
There are wide set of non-web applications that use UAG Socket Forwarding / Application Tunneling as a publishing method. For example, such applications are Citrix XenApps and Presentation Server 4.5, and they both run as ActiveX applications in browser. Before this update, because of technical limitations, we disallow deployment of those publishing methods on 64-bit version of client operating systems. Therefore, the same published application that uses those methods may be accessed from 32-bit version of client operating systemss instead of from 64-bit operating systems.
The change made for this scenario is to provide a method of deployment for the Socket Forwarding (SF) client components on 64-bit version of Windows client operating systems to enable opening of tunneled applications. The limitations of this implementation are as follows:
- Support for Socket Forwarder is limited to 64-bit version of Windows Vista and 64-bit version of Windows 7, other 64-bit version of operating systems are not supported.
- Socket Forwarder is only supported when users access UAG from the 32-bit version of Internet Explorer (running in WOW64 32 bit emulation).
- Socket Forwarder will only interact with 32-bit applications (WOW64 applications) and will not interact with native 64-bit applications.
The following are the deployment options for the updated components:
- Online: The standard method that performs deployment of SF components. On the very first invocation of any UAG portal application that uses SF as the tunneling publishing method, the components are downloaded and installed.
- Offline: Administrators can also deploy the appropriate Windows Installer application (MSI) on a client by using scripted software distribution or by manual installation. After the installation of UAG Update 2 the files will be available on the UAG server in the following location:
%UAG installation directory%\von\PortalHomePage\
Issue 4
SymptomYou cannot access Citrix XenApps 5.0 that is published with UAG from a client computer that is running a 64-bit version of Windows Vista or Window 7.
CauseThis is the designed behavior of the UAG client components before the release of UAG Update 2.
ResolutionRefer to the “Resolution” section of Issue 3 for detailed information.
Issue 5
SymptomWhen you try to create or edit an endpoint policy, the “McAfee Total Protection” policy appears two times on the list. If you select the second “McAfee Total Protection” policy, you receive an error message that resembles the following:
source line could not be located
CauseThis issue occurs because the %UAG installation directory%\von\Conf\PolicyDefinitions.xml file contains two entries that have the same title and ID.
ResolutionThe double entry issue is resolved by removing the second record from the PolicyDefinitions.xml file.
Issue 6
Symptom
When you access a resource that is published by UAG, clients receive an error "An unknown error occurred while processing the certificate" in the browser. Also, the UAG administrator may see in UAG server debug logs that
SEC_I_CONTINUE_NEEDED is returned during the SSL negotiation step "Handshake Confirm State." Following that step the debug logs will show that the
/InternalSite/InternalError.asp page is returned to the client together with error code 37. Error Code 37 is the error message "An unknown error occurred while processing the certificate."
Cause
The existing SSL mechanism does not correctly handli several scenarios when it performs SSL handshake with a back-end server published through UAG. The streaming nature of SSL creates a complicated scenario with a possibility of receiving either insufficient data or reading too much information during the handshake. In this scenario,
InitializeSecurityContext reports that you have passed additional data that must be saved for use in the future (presumably after you read more data across the wire).
Resolution
The handshake algorithm is extended to support additional streaming cases and scenarios.
Issue 7
Symptom
When you access a published HTTPS application through UAG, the user receives error 37: "An unknown error occurred while processing the certificate." An administrator who is doing debug logging (that includes the SSLBOX_BASE trace ) while the user is accessing the application will see the following error message:
ERROR:Failed to initialize security context. Returned error: 0x90320.
InitializeSecurityContext return SEC_INCOMPLETE_CREDENTIALS – Schannel requires client certificate credentials
Cause
The back-end application server is configured to ask for client certificate credentials during the SSL negotiation stage. Before this update such functionality was not supported. Therefore, the negotiation failed with an error.
Resolution
There are two possible scenarios where the back-end server is asking for client certificate credentials:
- The back-end application server is requesting a client certificate to obtain a certificate context but does not require it. For this case a fallback was implemented allowing UAG to retry the negotiation after the SEC_INCOMPLETE_CREDENTIALS return code is received. Usually the back-end server does not require the client certificate and this negotiation is successfully completed.
- The back-end application requires client certificate authentication. The design change that was implemented does not allow for the client to supply pass through client certificates but does allow for a single valid client certificate to be supplied to the back-end web server for all users.
For this case the UAG Administrator should supply a valid client certificate and install it on UAG server as a machine certificate.- To instruct the UAG SSLBox module to retrieve and obtain the correct certificate, follow these steps:
- Run the MMC command to open the management console.
- Click File, and then click Add/Remove Snap-in.
- Select Certificates from the list, and then click Add.
- Select computer account, and then click Finish.
- Open the Personal certificate store.
- Select the required client authentication certificate from the list and double-click the certificate.Or, right-click the certificate and then click Open.
- Select the Details pane and scroll down.
- Select Thumbprint property.
- Select the property value in the panel bellow and copy its value by pressing CTRL+C.
- Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
a. Start Registry Editor (Regedt32.exe).
b. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\UrlFilter\Comm\SSL
c. On the Edit menu, click Add Value, and then add the following registry value:Value name: ClientCertHash
Data type: String
Value: {the text copied in step 9} [for example: a7 36 4b ca 87 3f 10 ac d5 4b 0f ca 83 9e 9e 74 c8 3e fa 8b]
d. Exit Registry Editor.
e. Run IISReset as an administrator to restart IIS.
f. Activate the UAG Configuration.
Issue 8Symptom
In some rare cases client computers that have UAG Client Components installed on them receive a "uagqecsvc" event ID 85 log message written to the Windows Event logs every minute when that client is communicating with a UAG Server. Although this a false alarm, this fills up the client event logs making it difficult for administrators or the helpdesk from spotting real events in the client’s Windows Event logs. These messages will always be displayed on the client every minute if that client connects to an IAG server.
Event ID: 85
Source: uagqecsvc
Type: Error
Description: The Microsoft Forefront UAG Quarantine Enforcement Client component cannot initialize the enforcement client callback HRESULT value: 0x8027000E. This issue may occur if security policies do not enable the component.
There may also be another related event in the client event logs.
Event ID: 16
Source: uagqecsvc
Log Name: Application
Description: The Microsoft Forefront UAG Quarantine Enforcement Client component cannot retrieve the status of the Network Access Protection (NAP) Agent service. System error 1115: A system shutdown is in progress. (0x45b). When the Microsoft Forefront UAG Quarantine Enforcement Client component starts, it attempts to query settings of the NAP agent service.
Although this issue is not directly related to UAG or to UAG deployments, it is possible that with some deployments users who have the UAG client components installed on them will access both IAG and UAG servers.
Cause
UAG Client Components have a component service "uagqecsvc" with a display name of "Microsoft Forefront UAG Quarantine Enforcement Client" which queries endpoint health status by using NAP and reports the status back to the NAP module on UAG. In some rare cases this issue will be seen in UAG deployments as the service re-tries repeatedly to bind to the UAG server. The bind will run in loop with a minute time-out until it can connect.
Additionally starting with IAG Service Pack 2 Update 3, the UAG Client Components were ported to IAG. Therefore the uagqecsvc service is also installed on client computers that connect to any IAG server that has Service Pack 2 Update 3 client components. Because NAP endpoint detection functionality does not exist in IAG, the client that has the UAG components installed on them will continue to try to connect to the UAG NAP service every minute, in the process generating the previously mentioned log messaged in the Windows Event logs.
Resolution
In the earlier versions of the Client Components the default time-out for retries to communicate with the UAG NAP detection agent was set to a minute, it is been changed in UAG Update 2 to one hour. For administrators who want to modify this value a way to manually define the time-out on the client is provided.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 How to back up and restore the registry in Windows
Computer users or administrators can manually define on any client computer the time-out in milliseconds. To do this, follow these steps:
- Start Registry Editor (Regedt32.exe).
- Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\Client\QEC
- On the Edit menu, click Add Value, and then add the following registry value:
Value name: InitRetryTimeout
Data type: REG_DWORD
Radix: Decimal
Value: (time in Milliseconds 360000 is the default but this value must be
set larger then 6000)
- Exit Registry Editor.
- Restart your computer.
Issue 9SymptomYou (UAG administrator) have UAG installed on a server that is running a localized APAC language version of Windows 2008 R2. When you try to create a trunk on UAG, you receive an error message and the creating of trunk is stopped.
For example, blank windows, unexpected error messages, or frequent MMC crashes occur when you try to create a trunk on UAG.
CauseThis issue occurs because of incorrect manipulations of system resources. These incorrect manipulations lead to a failure when you run UAG on some non-Western language versions of operating systems (Korean/Japanese/Chinese).
ResolutionThe code that is responsible for accessing these system resources is fixed.
Issue 10
SymptomEndpoint Session Cleanup Component does not start to execute after a restart of an endpoint. Additionally, an explorer window opens that points to client components folder after a restart.
CauseBefore a restart, Endpoint Session Cleanup Component writes a registry value under the “Run” key. This registry value allows Windows to start Endpoint Session Cleanup Component automatically after a restart. However, this path value of registry key is an executable path that contains spaces. Therefore, a failure occurs.
ResolutionThe path value that points to the Attachment Wiper executable that is written under the “Run” key is now written as a quoted string to prevent any failures.
Issue 11
SymptomWhen you try to access the language setting options in Exchange Server 2007 Outlook Web Application (OWA) that are published via UAG, the following error message will be sent to the client.
You have attempted to access a restricted URL.
CauseThis issue occurs because the out of box template for Exchange Server 2007 OWA does not have a RuleSet entry for the URL"/owa/languageselection.aspx". The UAG RuleSet mechanism does not allow the access to any URL that is not in the white list.
ResolutionA new rule is added for Exchange 2007 OWA publishing to allow the access to this URL resource. In this case, the new rule " ExchangePub2007_Rule36 " allows the access to the URL "/owa/languageselection.aspx ".
Issue 12
SymptomWhen an user tries to access a UAG site, or tries to access a bookmarked path within the application rather than the UAG login path, the user receives a 500 Internal Server error and is unable to access the site.
Note The UAG site uses ADFS for authentication and directly requests a published application.
CauseWhen UAG is configured to use ADFS for authentication, several redirects occur between the Security Token Service (STS) and the UAG internal site. If the redirectes are not done in the expected manner, UAG returns errors. When a user tries to directly access a published resource instead of the portal site, the re-routing process is broken. Therefore, internal server error occurs.
ResolutionThis issue is fixed in this update.
Issue 13 SymptomWhen an administrator is configuring an ActiveDirectory type authentication repository, the administrator cannot set the group nesting value to "unlimited". According to UAG specification, the value of the group nesting field could be blank. However, when the field is blank and the configuration is saved and activated, the value is set back to "0" unexpectedly.
Note The UAG MMC needs to be closed and re-opened in order to get the value of "0" visible. As UAG specification, "0" means that there is no group nesting. Therefore, group nesting does not work as expected.
CauseThis issue occurs because the correct value for the group nesting field cannot be stored in the configuration. Therefore, the correct value cannot be applied to both the GUI and the authentication functions.
ResolutionThe value in the configuration is now properly stored and updated when the group nesting value is deleted from the GUI Additionally, the value is properly applied to the authentication functions.
Note Microsoft recommends setting the value to be the lowest number that is required for the authorization in UAG. You can set the value to higher than 2 levels of nesting due to the potential delay and the required resources. If higher than 2 levels are required for a deployment, you must test the impact of these changes before the system is deployed in production. In extreme cases, these settings can cause both the UAG server and any DCs that are being used for authentication by UAG to crash because of high resource demands.
Issue 14
SymptomWhen you try to close the Network connector (NC) server configuration window after you enable the NC server, you may receive the following error message:
Wrong Network Connector parameters, invalid segment address
CauseThe SSL Network Tunneling service can be used only when the physical network adapters have MAC addresses that begin with "00".
ResolutionThe SSL Network Tunneling service can be used even though the physical network adapters have MAC addresses that begin with "00".
Issue 15
SymptomUAG was released with only partial support for Citrix XenApp 5.
When you want to publish Citrix without errors, they were obligated to follow the steps that are provided in the following Microsoft website:
CauseThis issue occurs because the support for Citrix is broken.
ResolutionThe steps that are provided in the above to properly publish Citrix XenApp 5.0 are now included in this update.
Issue 16
SymptomThe AV product "Trend Micro OfficeScan Anti-Virus" or "Trend Micro PC-Cillin Anti-Virus" is selected from the GUI. In this case, when you create a policy and then apply the policy to an application, you receive the following error message during the activation:
Source Line could not be located
CauseThis issue occurs because the policy syntax validation algorithm misses dependencies that are required by these particular policies.
ResolutionThe dependencies that are required by these policies are added to policy syntax validation algorithm after you install this update.
Known issues
- After you install this update the SSL Network Tunneling network adapter becomes invisible in the Network Connections window. This behavior is by design. To make sure that the network adapter is installed open Device Manager and select ‘Show Hidden Devices’ entry on the View menu.
- Sometimes the uninstall update operation may fail with an error message, specifying that the installation file “FirefrontUAG.msi” cannot be found or with the installation error 1269.
- Open Start menu and type Show hidden files and folders.
- In the opened window advanced settings clear the Hide protected operation system files (Recommended) option and press OK.
- Open an elevated Command Prompt window and type UninstallUagUpdate.
- Wait several minutes for the installation database repair if it is required.
Note You might receive a message that informs you of the need for a repair.
- Citrix XenApp support is only for version 5.0. Later versions are not supported.
- This release only supports the Personal Desktop scenario of VDI. Pooled desktop scenario is currently not supported.
- Socket Forwarding is available on Window 7 and Vista 64 bit clients for 32 bit applications (WOW64 applications). It is not available for native 64 bit applications.
- Publishing OWA for Exchange 2010 Service Pack 1 by UAG requires manual modification of an AppWrap and modifications to the RuleSets. An article about the steps that are required to do this is published on the UAG Product team blog http://blogs.technet.com/b/edgeaccessblog/. The steps that are described in the article will be integrated into a future update of UAG.
- Microsoft Customer Support Services (CSS) cannot provide support to customers if they use beta, non-RTM, or non-generally-available (GA) products such as Internet Explorer 9 Beta. Support for IE9 will be included in a future update after IE9 is officially released.
Known issues with Arrays and Network Load Balancing (NLB)
- When you try to join two servers to the same array at the same time, the array storage may be corrupted. If this happens, restore the settings from backup.
- When you delete an IPv6 virtual IP address (VIP) in the Forefront UAG Management console, the address may not be removed completely. To work around this issue, manually delete address from the network adapter in the Network and Sharing Center and in the Forefront UAG Management console.
- Forefront UAG may not detect that an array member which uses integrated NLB loses network connectivity (such as an ISP system-failure). In this scenario, Forefront UAG may continue to route traffic to the unavailable server. To avoid this issue, disable the internal and external adapters of offline array members. Enable the adapters again after connectivity issues are resolved.
- If you have Microsoft System Center Operations Manager 2007 deployed in your organization, you can monitor the status of array member network adapters. To do this, follow these steps:
- Make sure that the Windows Server Operating System and Windows Server 2008 NLB management packs are installed on each array member.
- Use Operations Manager 2007 to detect disconnected network adapters on array members.
Note Operations Manager 2007 reports issues as follows:
- If there is a problem with the adapter that is connected to the internal network, Operations Manager 2007 reports that no heartbeat is detected.
- If there is a problem with the adapter that is connected to the external network, Operations Manager 2007 reports a Windows NLB issue.
- When you create a redirect trunk for an HTTPS trunk in an array that does not have load balancing enabled, you must manually assign the IP addresses of the redirect trunk for each array member. This task is described in the following article: