What are Trunks and Applications?
Just as we like to organize everything in life into containers, UAG also does the same. As a user of Microsoft products, you are probably used to files or programs that are grouped together within folders and which are stored on hard drives (or hard drive partitions). With UAG, there’s one little difference, the primary organizational units are called “Trunks”, and in those we create (or “publish”) applications, and we can also group them in folders too. The reason for this difference in naming goes back into the distant past, but it doesn’t really matter.
The first step when starting to publish applications with UAG is to create a Trunk, and then, add applications to it, as needed. A UAG server can contain multiple trunks, depending on how many IP addresses are assigned to its external interface. Some organizations need only a single application on a single trunk, while others publish multiple trunks, with dozens of applications on each of them. If many applications need to be published on a single trunk, the administrator can also organize them into folders, which can make it easier for users to find.
An “application” for UAG is a collection of settings and rules that determine how UAG publishes a certain internal website or application. These settings include, among others, the name or IP address of the internal server that will be published, what files and folders are accessible by the end users, and which users have access to what.
At any point, an administrator can add IP addresses to the external NIC of the UAG server, add public DNS mappings to these addresses, and add more trunks. This is also an alternative way to organize the various applications—some organizations publish several Portals with different addresses, and provide the public URLs to groups of employees based on their needs. That is done, of course, in addition to defining the authorization on the trunks themselves.
Types of trunks
When creating a trunk, you can create trunks of two distinct types—HTTP (where traffic between the client and UAG is sent unencrypted as “clear-text”) trunks and HTTPS (or “secure”) trunks. The difference between these is simple—HTTP trunks are accessible by users over the HTTP protocol, while HTTPS trunks require the browser to communicate with encryption. Some UAG customers are perfectly fine with using HTTP trunks, but most customers prefer the more secure HTTPS trunks, because their users will be sending and receiving sensitive data over the link. From a technical perspective, a trunk is a website running on the IIS server that is active on the UAG server, and just like any other website in the world, it has an IP address and a TCP/IP port. If you have a single IP address assigned to the external NIC, you can choose to publish a single HTTP or HTTPS trunk on it. Naturally, you can choose to publish zero trunks, but for that, you don’t need this article, or any article, really.
For those of you familiar with previous products, such as e-Gap and IAG, you might be familiar with several types of trunks, such as Basic and Webmail, but UAG no longer has these. UAG does not support publishing trunks on ports other than 80 and 443 either. It does, however, support Redirect trunks. A redirect trunk is meant to make it easier for an organization’s users to connect to their server easily when the UAG portal is published as an HTTPS trunk. This is useful, because most users are used to typing HTTP URLs into their browsers, and if they forget to type the HTTPS:// prefix to the URL, the browser will assume it is HTTP, and receive no response on port 80. The Redirect Trunk will listen on port 80, receive the request and reply with a “redirect” HTTP 302 response code, asking the user’s browser to request the same web address, but with the HTTPS prefix. It is important to note that a redirect trunk is only available to redirect users from HTTP to HTTPS, and not the other way around. Therefore, on the UAG configuration console, the option for a Redirect Trunk is only available in the HTTP trunk wizard.
A redirect trunk can only be created after the HTTPS trunk it needs to redirect to, has been created.
A Basic trunk used to be available in IAG and e-Gap as a means of publishing a single web application on a single trunk, without going through a portal. Even though UAG does not offer a Basic trunk, there is still a way to achieve the same functionality, and we shall discuss this further along the way. A Webmail trunk was used with the previous versions of the product to publish, as the name indicates, webmail types of applications, such as different versions of Outlook Web Access (OWA), or Lotus Notes, as well as the now out-dated Outlook Mobile Access for Exchange 2003, and the Exchange ActiveSync Service, which allows Mobile phones running Windows Mobile to sync over the internet with Exchange servers. This trunk type is no longer available either, but you can still get the same functionality via the use of the Exchange publishing wizard on a UAG Portal trunk
Following the demise of the Basic and Webmail trunks, the remaining options when creating new trunks are Portal trunks, and ADFS trunks. A portal trunk is the home page of UAG—it will be the home for all the applications you will be publishing on your UAG server. Users who log in to the trunk remotely will see these applications as a list of icons and links referred to as the Portal Home Page, and clicking on any of these will launch the specific application, whatever they may be.
Another type of trunk that exists with UAG is the ADFS trunk. ADFS, or Active Directory Federation Services, is a technology that allows organizations to provide Single Sign-On (SSO) for users from different Active Directory forests. ADFS (sometimes written as “AD FS”) has been a part of the Windows Server world since the release of Windows Server 2003 R2, and it is used primarily by large organizations. Such organizations can use ADFS to allow users which belong to one forest to access resources in another forest without requiring the need to sign on again. This nice trick can benefit an organization that has multiple forests, or an organization that needs to cooperate tightly with another organization, such as a business partner. This also means that the two organizations do not need to have a shared user database of any kind.
For UAG, this means that users can log on to the portal, and access published applications on servers that belong to another organization quickly and easily.