One of the challenges facing many customers is the need to publish an application for stateless clients. This typically involves a non-interactive application, like a program running on an un-attended computer, and connecting to retrieve data automatically from another organization. Some customers attempt to employ UAG for this type of scenario, using an unauthenticated trunk:

Essentially, disabling trunk authentication in the Advanced Trunk Configuration turns UAG into a transparent proxy, providing functionality comparable to using a Server Publishing rule in TMG. However, some users have run into issues with this scenario. The issue presents itself as a “loop” experienced by the application when it tries to access a URL through UAG. Instead of getting the expected HTML data from the backend server, UAG replies with a redirect to the InitParams.aspx page, followed by a redirect to the InternalError.asp page, with error 109. As the application requests the Internal Error page, UAG replies to that with another redirect to the InitParams page, and this starts a loop that could go on until the application decides to drop the attempt.

The reason this is happening is because UAG is designed to interact with browsers*, and part of this interaction is the session cookie issued by UAG. When a client creates a new connection, UAG will issue such a cookie, and will expect it upon subsequent connections. Even a connection without authentication requires some interaction with UAG (the session parameters initialization page mentioned earlier), and that means that if a client is unable to store the session cookie, respond to HTTP redirect commands and reply with the cookie upon subsequent requests, UAG will not be able to service it.

This mechanism is part of UAGs design, and is a security mechanism that cannot be disabled. This means that stateless clients need to meet those requirements in order to be able to interact with UAG. Depending on the application and the platform it was built on, this change could be simple. Unfortunately, though, if the application cannot be made to behave this way, UAG will not be able to provide it with access, and the only alternative is to use TMG (or comparable firewall publishing solutions) instead. I should also note that the list of supported clients for UAG is listed here, and other clients are unsupported. This means that if you are creating your own client, even if it runs on a supported platform, it is not automatically supported by UAG. If it’s built well and in accord with public internet RFCs, it should work, but that is not guaranteed, and is not supportable by Microsoft.

* There are some exceptions to this. For some scenarios, UAG does behave differently. Once such exception is the interaction with office applications, which are considered to be “rich” clients, and have another mechanism to interact with the back-end server (SharePoint) via UAG.