|Read more about this book|
(For more resources on Microsoft, see here.)
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.
|Read more about this book|
(For more resources on Microsoft, see here.)
Types of applications
Once a portal trunk has been setup, be it an HTTP or HTTPS trunk, you can start publishing applications on it. Applications are published using a wizard, which includes approximately 40 types of application templates. Some of these are just alternative ways of publishing the same application, and some would be better described as services rather than as applications.
The top-level type list is divided into the following categories of applications:
- Built-in services
- Web (applications)
- Client/Server and Legacy
- Terminal Services and Remote Desktop
Each of the previous groups have unique characteristics that make it suitable for publishing specific types of applications, based on how these are designed and what components they use.
Built-in services are the Portal application itself, File-Access and the Web-Monitor. The portal application is automatically added to a trunk when you create a portal trunk, so you do not need to use it unless you delete the portal application for some reason and need to recreate it. The File-Access service allows users to download or upload files directly from internal file servers. The Web-Monitor is a built-in website that's automatically created when you install UAG, and publishing it on the portal allows an administrator to view and manage aspects of the portal remotely.
The "Web" family of application templates is probably your main focus, as it contains templates for the most important Microsoft Servers— SharePoint and Exchange?. It also contains templates for Forefront Identity Manager 2010, Microsoft Dynamics CRM 4, Office Communicator Web Access 2007, Rights Management Services, Active Directory Federation Services 2.0 and most importantly—Other Web Application. The "other" web application is the most generic template, and will be your best bet for most applications that do not have a specific template assigned for them. That doesn't mean it can be used for everything else, but it is extremely flexible and it will work flawlessly for thousands of web applications.
Client/Server and Legacy
The third group, Client/Server and Legacy, which is also extremely useful, is designed for applications that go beyond being a simple website by integrating external components. These applications cannot be published like regular ones, because they run outside the browser.
In the case of applications that are Client/Server TCP/IP based, the user will be running something other than a web browser, and the internal server may be something other than a web-server. For example, the client component may be a CRM application, and the backend server may be a database server. To handle such applications, UAG contains tunneling components. These are part of the UAG's client components, which are installed on a client machine automatically when required. When a Client/Server based application is launched, the client components launch a special listener that listens for communication attempts from the client application, encrypts them using SSL, and sends them to the backend server through the UAG. At the other end of the tunnel, UAG listens to responses from the backend server, and these are sent back to the client through the UAG client components. All of this is done silently, in the background, although the user can observe that something is happening in the form of a special icon that appears in their System-Tray:
The tunnelling technique described previously is extremely versatile and using the templates that are in that group allows incredible types of connectivity to happen. Using the enhanced generic client application template, for example, allows you to do pretty much anything.
Another important application in the "Client/Server and Legacy" group is Remote Network Access. If you are familiar with IAG, you might recognize that as "Network Connector". Remote Network Access is an application that creates a fully fledged VPN connection to the corporate network, including IP assignment, DNS, and, of course, full SSL encryption of the traffic. We will discuss Remote Network Access in more detail later on, but it's considered by many to be one of the most important and useful abilities of UAG.
The fourth group of application templates is Browser-embedded, which are somewhat similar to Client/Server applications. In this case, the software used by the users to do their work is not a browser, but a piece of standalone code that is embedded in the browser. You can think of it as a middle ground between a standalone "client" application and a browser. This group, for veteran IAG users, used to contain many applications in IAG, but with UAG, it contains but two items. One is Citrix XenApp, and the other is simply a generic browser-embedded application template. Citrix is a classic browser embedded application, in which a link on a webpage causes an ActiveX version of the Citrix Client. The ActiveX runs within the browser, but it's also a standalone executable, so it requires a tunnel to be able to communicate to the back-end Citrix server. The Citrix XenApp UAG application template creates a tunnel in a way that's identical to the way Client/Server application templates do.
Many customers are not very happy about the fact that UAG misses so many of the Browser-embedded templates they grew to appreciate with IAG, but the fact of the matter is that the generic browser-embedded application template is actually capable of publishing almost all of these applications quite easily. It requires the UAG administrator to know the properties of the applications, like the TCP/IP ports that they use, but other than that, it's all pretty smooth.
Terminal Services (TS) / Remote Desktop Services (RDS)
The final group is Terminal Services (TS)/Remote Desktop Services (RDS), which is a collection of five templates used to provide access to internal servers via the RDP protocol. This is pretty straightforward, although the various templates each serve slightly different purposes. Some organizations use these to allow the organization's network administrators to connect to their servers from home and manage them, while others let users use an internal terminal sever to do routine work. Using Terminal Servers in this manner provides a smooth and secure work environment, because the Terminal Server that the user connects to is already configured with various applications that the user may require. Also, these servers are actually inside the organizational network, so the environment is a very close match to what the user is used to from working at the office.
What is URL signing and how does it work?
An important part of the way UAG handles applications is the process of URL signing, also known as Host Address Translation (HAT). ?The URL signing mechanism is what allows the UAG server to publish multiple servers from within the organization, all on a single IP and port.
To understand how HAT works, and why it's needed, let's consider a regular website. The user types in a URL into his browser, which retrieves it from the server. The web page typically contains links. These can be images, which the browser automatically retrieves from the server, or actionable items, such as 'blue' links to other pages or various types of action buttons. These links can point to resources on the same server or another.
When a page is visited through UAG, we have a challenge. The back-end server has a certain name, which is often part of the links. For example, the page http://accounting01/home.htm may have a link to http://accounting01/tax/calc.htm. If the accounting server is published through a UAG portal named https://uag.createhive.com, and the user clicks on the calc.htm link, his browser will try to contact the server accounting01, which is not reachable directly from the Internet. This is what HAT solves for us.
When UAG delivers a page to the user, it has a special engine that goes through all the links on the page and rewrites them. If it finds a link to an internal server name, it changes it to point to UAG's own portal hostname, so that when the link is "activated", it will reach the UAG server. When that happens, UAG also needs to know to which of the applications that it is publishing this relates to (in other words, from which of the many internal servers that the organization has is UAG supposed to retrieve the actual resource). To this end, UAG adds a unique alphanumeric string to each link. For example: https://ap.createhive.com/uniquesig48cb675c4745e7d473e210fdf4f89f67/uniquesig0/tax/calc.htm
Then, when a request arrives for this link, UAG decodes back the string (also called 'Signature') and knows that this request is for the accounting01 server, and proceeds to retrieve the requested file from it.
To the end-user, all of this is transparent—he just sees pages delivered, and all is great. If, however, you view the source of pages delivered by UAG, you will find that every link on the page that normally points to an internal server is "signed", similarly to the previous example. The signature strings are unique to each server that UAG is publishing, and if an application is configured to use multiple servers, we might find multiple signatures in one file.
For some applications, the link parsing is so difficult that we don't even bother trying. One such example is SharePoint. SharePoint pages are so complex, that the SharePoint development team actually had to write a special component called Alternate Access Mappings (AAM), which helps UAG and other publishing products to handle it. This means that when publishing SharePoint servers, HAT is not done at all,
Designing your trunks, applications, and nesting
When publishing applications, the number of applications is not limited beyond the hardware capabilities of the server, though one should consider general User-Interface design considerations. Creating a huge page with dozens of buttons is cool, in some people's opinion, but a general approach says that having no more than eight items on any menu is a good practice. This number is not set in stone, and you can always create some folders and divide the applications logically between them. Another thing to keep in mind is that the applications you define on a trunk will be displayed on-screen arranged from left to right, and from top to bottom, alphabetically. If it's important to you to have the applications appear in a certain order, the only means of controlling that is by naming them in a way that will force UAG to sort them to your liking. For example, you could name all RDP related applications with the prefix RDP ("RDP Exchange", "RDP SQL", and so on), so these will be grouped together, or have each application name start with a number. Another thing you can do to make things easier for users is to assign specific icons that differ from the default, to an application.
Technically, you should be aware of one important fact. UAG has a security mechanism for web publishing that inspects the HTTP requests sent by clients to UAG and decides if these should be sent to backend web applications. This is very useful for several reasons:
- It allows you to block access to parts of the applications that you don't want people to use, such as the part that manages settings, or the part that controls the applications' permissions and authorization.
- It allows you to block specific commands or parameters that might be undesirable or dangerous. For example, certain URL parameters can be blocked in a way that prevents OWA (Outlook Web Access) users from uploading or downloading attachments.
- It allows you to block URL and parameter combinations that pose a risk, such as cross-site scripting or attacks that exploit faulty input validations in applications.
The access rules mechanism is controlled using the Trunk Configuration URL Set tab.
What you do need to realize now, though, is that the rules are named and applied according to an application's type, which is determined by the template you select. Most templates have a fixed type, but the generic templates allow you to enter anything you want as the type. What's important to remember here is that if you publish multiple applications with the same type, the same access rules will apply to all of them. This could be a good idea and a time saver if you do indeed need all these applications to have the same level of access but, if not, you must keep this trinket of information in mind.
Some common applications and the appropriate templates
At this point, you might be thinking to yourself something along the lines of "Hmmm...I bought this product, which is supposed to publish everything, to publish my fabulous and unique _____ server. Now you're saying I am the one who's supposed to pick and choose?!?!" Well, in short, yes. The long answer, though, is that UAG is certainly not "supposed" to publish "everything". It's extremely versatile and flexible, but each application and service has its own characteristics, and some can be difficult, or even impossible to publish.
Some applications will require careful analysis and planning and, occasionally, some trial and error.
DNS name resolution
For most organizations, the UAG portal and applications are there for employees or partners to use from the public Internet, from home, or while travelling. UAG is designed to be accessed using a host-name that is typed into the browser on a user's computer. This means that the client computers need a way to perform name resolution for the server, and for that, you will have to create a host entry on your public DNS server. For some organizations, this can be tricky, if the DNS is hosted by an ISP, or if such change requires assistance from another team within the company. Some companies have very strict change-control procedures, and some hoops will have to be jumped through to get this done. If that is the case, it would be a good idea to get to that early, so it doesn't hamper the production schedule. As an option, you can also use an alternative, such as adding a static entry to the HOSTS file on your client computers, though that could be quite a hassle for a large organization. As a temporary means of testing the server, though, it could work well.
Another thing to keep in mind is that the UAG server itself needs to have the ability to perform name resolution of internal hostnames of servers it is publishing. It may also need to be able to do so for public URLs. For example, if you plan on publishing internal servers that use HTTPS, the UAG server will have to be able to accept their server certificates. If those certificates have a CDP (CRL Distribution Point, where CRL stands for Certificate Revocation List) URL embedded in them, like most certificates do, then UAG will need to be able to resolve the CDP URL. If those certificates have been issued by a public CA (Certificate Authority) like VeriSign or Thawte, then UAG will need to be able to resolve and contact the public CRLs of those providers. Whether UAG uses internal DNS servers, external ones, or both, the proper routing and access-control needs to be thoughtout.
This is a good opportunity to mention a new behaviour in Windows Server 2008, which is different to older versions of Windows Server. The new TCP/IP stack in Windows uses a new model when choosing the IP address it uses as a "source" (this refers only to systems that have more than one IP address assigned to a Network Card). You can think of this like choosing which exit you use when you leave your town to get on the highway. Some people choose the closest one, while others prefer the one that has a drive-through coffee stand or one with a gas station. In previous versions of Windows, the system would always use the primary host, but with Windows Server 2008 (as well as Vista), the source IP is selected based on a set of rules that may cause it to use another IP. This could cause a bit of confusion in case you have some traffic-control mechanism to govern traffic coming out of the server, such as a firewall or load balancer. For example, if you have set your external firewall to allow access only on certain ports/IP combinations, you may find that some traffic is inexplicitly blocked. To read more about the new TCP/IP stack in Windows Server 2008, read the following articles:
In this article, we covered UAG's building blocks—Trunks and Applications and reviewed the various types of each.
In the next article we will see how to prepare, create and publish an HTTPS Trunk.
- Microsoft SQL Azure Tools [Article]
- Microsoft Azure Blob Storage [Article]
- Setting up the Microsoft Dynamics GP System [Article]
- Introduction to Cloud Computing in Microsoft Azure [Article]
- 3D Animation Techniques with XNA Game Studio 4.0 [Article]