Richard Barker - Forefront Edge

Behavior of the “Logoff URL” option

Richard Barker - MSFT — Fri, 11 May 2012 17:07:27 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”

Richard Barker - MSFT — Fri, 11 May 2012 16:57:26 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

DirectAccess Connectivity Assistant polling interval

Richard Barker - MSFT — Tue, 20 Dec 2011 14:01:04 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 Assistance, 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

Richard Barker - MSFT — Thu, 08 Dec 2011 15:48:07 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