|Read more about this book|
(For more resources on Microsoft, see here.)
Preparing for an HTTPS trunk
We have chosen to talk about HTTPS first, because these trunks are the most used by UAG customers and because, well, HTTP trunks are as easy as pie. Creating an HTTPS trunk is not difficult but, before going there, you need to have a certificate, and this can make your whole day rainy.
The HTTPS protocol provides better security as it encrypts the traffic between the user and the server. This is an age old protocol that has stood the test of time well, but it may still be a bit challenging to use, because just like real-life certificates, digital ones can't just be handed out by anyone. Many books have been written about PKI (public key infrastructure), so we won't go into much detail about it, but it's important to understand the basics, so here goes.
Encryption is based on a simple concept. You want to send data to someone without anyone else being able to read it. You take the data, and change it in a way that only you and the future recipient know. If that data falls into the wrong hands, it will look like meaningless garbage. The intended recipient, though, knows how to reverse the process and read it.
Encryption is done by taking a key, which is a very long and unique number, and using it to perform a mathematical function on the data, resulting in encrypted data that appears to be meaningless. To decrypt the data, you do the opposite, with the same number, and obtain the original data. Let's do a simple example:
Suppose you want to encrypt the word RIDDLE:
- First, you convert each letter to a number. If we start with A=1, B=2, we get 18, 9, 4, 4, 12, and 5.
- Second, we "encrypt" the data with our key. Let's say our key is "50", so we just add the key to each number, and end up with 68, 59, 54, 54, 62, and 55.
- Now, when it's time to decrypt this sequence, we just subtract the same number back, and convert font to letters.
Naturally, that level of secrecy wouldn't be too hard to break, but real key-based digital encryption is much more complicated – trust me!
The previous process is known as "symmetric" encryption, because the same key is used to encrypt and decrypt. In old-school espionage, the recipient would be equipped in advance with the knowledge or means to do the decryption. The problem with the internet is that the sender and recipient hardly ever meet, so we need to come up with a way to provide the recipient with the know-how, without it being intercepted along the way, because that will allow anyone who's smart enough to intercept internet traffic (which isn't very hard, really) to decrypt anything and listen in. To our help comes ASSYMETRIC encryption, and digital certificates.
Asymmetric encryption uses a special mathematical formula that generates two different keys, instead of one. We then use a special encryption formula that cannot be reversed with the same key. If you encrypt using the first key, you need the second to decrypt, and vice-versa. It's really quite a headache, but computers can do this sort of thing almost instantly. What happens when computers need to encrypt data is that the server (this could be your web server, for that matter) creates these two keys randomly. One is called the public key, and the other one the private key. Now, when that server wants to communicate securely with some other computer (say, your client), it sends it its public key (which is not secret—anyone is free to have it at any time), and then the client creates a unique and random regular key (like the one we discussed earlier). The client then encrypts the regular key using the server's public key, and sends it to the server. If you recall, the encrypted regular key stays secret, because even if someone intercepts that message, he can't decrypt it because, to do so, they would need the server's PRIVATE Key, which is kept really private and secret.
So, the encrypted regular key is received by the server, which decrypts it, and now both sides have a regular key that no one else knows, and they can start using it to encrypt and decrypt messages back-and-forth. Fantastic. One thing, though, still needs to be taken care of is—trust. Say you are a client, and a server sends you this nice encrypted key, how do you know it's really a genuine partner, and not some other server that impersonates it? Well, for that, we have digital certificates.
A digital certificate, like a real-world certificate, is a way to prove one's identity. When you want to get on a plane, you convince the security guard that you really are who you say you are by showing him a certificate given to you by the government—a passport or ID card, usually. It would have some unique seal or mark to prevent you from photo-shopping someone else's ID, and that allows the guard to trust you because he trusts the body that gave you that certificate. After all, the government (at least ours) won't hand out a passport randomly, right?
Well, a digital certificate is given out by special companies who give them out only after verifying the recipient's identity properly, and so everyone trusts them. Even if you have never heard of VeriSign, Thawte, Valicert, or Entrust, your computer has heard of them. If you open your local certificate store, you can see them, as well as several others. To do so, open the Internet Control Panel, and switch to Content. Click on Publishers, and switch to Trusted Root Certificate Authorities, and voila:
Once you have a digital certificate, you install it on the server it was intended for, and then, your server can present it to clients which attempt to connect to it. These clients check if the certificate is a match to the server by comparing the server's URL to the Common Name listed in the certificate. They also check if the certificate has not expired, if the certificate's issuer is a trustworthy one, and if that issuer hasn't revoked that certificate. If that is good and well, the whole encryption process discussed previously can continue. If something fails, the browser will alert you to that fact, and you can then decide if you want to take a risk and go ahead anyway, or walk away.
If you look at the previous screenshot, or your own computer's Trusted Root Certification Authorities, you will notice that your browser comes with a pre-populated list of all major Certificate companies, but some companies don't want to buy a certificate from them because it can cost a lot of money, hundreds of dollars in some cases. Instead, they set up their own Certificate Authorities within the organization. Anyone can do that really. In fact, all versions of Windows Server come with a built-in Certificate Authority server that can be enabled for free.
The challenge here is that such a server, by default, is not trusted by other computers unless they are configured to do so. This is done by installing the company's Certificate Authority's own certificate into each computer that needs to trust it. That could be a tedious process but, sometimes, it is inevitable.
So, going back to our HTTPS trunks, to enable computers on the internet to communicate with it securely, it has to be able to prove its identity to these computers by having a digital certificate. The rest of the encryption process is done automatically and there's no need to worry about it. Getting the certificate, though, requires some planning. We already said that the client checks four things:
- The certificate is issued by a trusted authority
- The certificate's URL matches the one it's assigned to
- The certificate has not expired (calendar-wise)
- The certificate has not been revoked by the publisher
|Read more about this book|
(For more resources on Microsoft, see here.)
Getting a certificate from a trusted publisher is not a problem—just pick one of the names on the list, or do a web search for it. If you're good at that sort of thing, you might land yourself a nice deal (word on the street is that you can find certificates for less than $20 a year). The URL is where it gets complicated. You probably already made up your mind about the public URL your portal will be accessible through, so you need to make sure that the certificate is for that URL. You can always change your mind, but that might require buying a new certificate, unless you have a wildcard or star certificate. This is a nice thing to have, because it allows you to publish multiple servers using the same certificate, though it does cost more than a regular one, of course.
For example, if you want to publish your UAG portal as https://uag.createhive.com, you can buy a certificate for *.createhive.com instead of the explicit uag.createhive.com. This way, if you later decide you want to change your portal to portal.createhive.com, there will be no need to mess around with the certificate. There's another advantage— publishing some applications with UAG requires the use of multiple public hostnames. SharePoint, for example, is such an application, and so is publishing Exchange Outlook Anywhere. Getting a wildcard certificate can make these go much smoother. Another option is getting a Subject Alternative Name (SAN) certificate, which is cheaper than a wildcard certificate, and can contain several (usually four) names within a single certificate.
After having bought the certificate, which could take a few days to finalize, all you have to do is install it on your server. The Certificate Authority will provide you with instructions on creating the certificate request, and then how to install the certificate file that they will send you. Once this is done, you are ready to create your first HTTPS trunk. Take note of the expiration date of your certificate—once it expires, you will need to renew, and it's better to do so a few days before it actually expires. Your server will not remind you of this, until you start getting those angry phone calls about clients receiving weird errors, so you might as well mark your calendar.
If your plan is to skip buying a certificate completely, you have two other options. One is using a self-signed certificate, and another is installing a corporate Certificate Authority server. These tasks are beyond the scope of this article, but you can read about them here:
If you choose to go down this path, keep in mind that you should establish trust by installing the appropriate root certificates on the client computers. If you don't, you will be prompted about the site's invalid certificate when you try to access it, and it may stop some components from working. For example, Remote-Desktop applications as well as SSTP are sensitive to invalid certificates, and will not work.
Creating an HTTPS trunk
To create an HTTPS trunk, open the Forefront UAG Management console on your server, right-click on the HTTPS Connections branch and select New Trunk. On the wizard, select Portal Trunk, but don't check the option Publish Exchange applications via the portal, even if you plan on doing so. You will be able to launch the Exchange publishing wizard at any point.
On the next page, type in a name for the trunk, and the Public hostname you selected earlier. The public hostname should not include the HTTPS:// prefix. Select the public IP address that will be assigned to it, or one of them, if there's more than one. Leave the port selection fields as they are, and don't worry about the "80" one – that does not mean it will be non-secure. Be careful about selecting the trunk name – it's not visible onscreen to the end-user, but it is part of the URL that the user might notice, so make sure it's something respectable and reasonable.
On the next wizard step, you will need an authentication repository, which will allow UAG to check the credentials of connecting users in Active Directory, or other authentication providers. To do so, click on Add, and then fill out the details of your authentication infrastructure. Type a Server name, which is just a name for the repository and click on Define, to configure the names of your servers. Keep in mind that the Repository is visible to the users in some scenarios, so the name should make sense or, at least, not be anything embarrassing.
Fill in the name of your AD Server and, optionally, a secondary one. If the UAG server is domain joined, this is not needed, and you can simply use the Use local AD forest authentication option. You can also select that the server uses SSL/TLS. If you are not the primary network engineer of your company, you might need some help obtaining these parameters.
Back to the Repository add page, click on the three dots next to Base DN to automatically populate that field. Depending on your domain infrastructure, you may need to edit it manually. You also have the option Include subfolders. Including subfolders means that when UAG checks the permissions for a user that is logging in, it can also check if the user belongs to a group that has permissions. For example, you may want to grant access permissions to an application, or to the portal, to a group named Accounting Department, rather than for individual users or for "everyone". In that case, you must enable subfolder search, and set the appropriate nesting level. By default, that is set to 0, which means that even if you checked Include subfolders, no actual crawling of the groups will be done. If the target users are inside groups that are themselves inside other groups, you should set a nesting level appropriately.
The "nesting level" settings tempt some to set it to a high number, in order to cover all their bases, but that's actually a bad idea. If you set the number to a high setting, it forces UAG to perform multiple queries against Active Directory, and that takes time. The result could be a big delay on logging in and, in extreme cases, even a nasty timeout. We recommend setting the nesting number as low as possible. For most companies, 1 or 2 would be sufficient.
The Server Access settings are a username and password combination of a user that will be impersonated by UAG to retrieve data from AD. You need to make sure that the user you choose will indeed have the appropriate permissions for this. Some organizations use the primary domain admin user, but a good security practice is to use a user that has the lowest level of permissions that will still suffice. Another thing to keep in mind about this is that if that user's password expires, and is reset, you need to update the UAG repository configuration accordingly, or authentication attempts will fail and access to the portal will be blocked.
Lastly, you might want to set a default domain name for your users. This is not mandatory, but, by setting it correctly you can make things easier for your users. If you specify a default domain, your users will not be required to enter their domain name when logging in.
It's important to keep in mind that this repository wizard also allows you to create other types of repositories, and not just ones that authenticate against Active Directory.
Once done with the repository, close the wizard and return to the Trunk creation wizard by selecting the repository you just created and clicking on Select. The next page requires you to select the certificate that will be used for this trunk and, assuming you have already taken care of buying and installing it, it should appear in the drop-down.
The next page in the wizard asks you to select if you want to use the standard UAG endpoint policies to control access to the portal, or use a NAP server. NAP (Network Access Protection) is a Microsoft technology used to check the health state of computers by checking that said computers meet certain, preset, requirements. For example, the company may wish that only computers that have all current Windows Updates installed to be allowed access to the network. If your network has NAP deployed, you can configure it here, although this is beyond the scope of this article.
If you selected Use Forefront UAG access policies, you will now be presented with two drop-down menus, which allow you to select the policies which will be enforced on connecting clients. Leave the settings at their default and move on.
The last wizard page summarizes your settings, and you can click on Finish. Remember that Activation we talked about earlier? Yup, it's time to do that again. You can do it by clicking on the Cog-Wheel icon that's on the top-left of the screen, or choose Activate from the File menu. The simplest way, though, is to press Ctrl+G. The Activation wizard will offer to backup your configuration before activation. There is not so much to backup at this point, but backing up often is certainly a good idea, and a good habit to make from day one. You will probably notice that the activation process takes even longer than it took before, and don't forget to track it with the Activation Monitor to make sure it's really over, despite hearing no singing. The activation monitor is a separate application that you can find next to the UAG management console on your Start menu. It shows the activation status for your server, and once the activation is really finished, it will show a long output that describes some of the work the server has been doing during the activation. Once done, you can fire up a browser on your test client, and connect to the portal. Take a few minutes to enjoy and appreciate the fruit of your hard work!
(Move the mouse over the image to enlarge it.)
|Read more about this book|
(For more resources on Microsoft, see here.)
Publishing an HTTP trunk
The HTTP trunk publishing wizard is virtually identical to the HTTPS one, except for the Certificate selection page, which you won't see. Another difference is the option to select a Redirect Trunk.
If you have selected the HTTP to HTTPS redirection trunk, then the next page of the wizard will ask you to select to which trunk you want the redirection to be done.
Note that if you have not yet created an HTTPS trunk, you will not be able to continue this wizard. Also, you can only create one redirect trunk per HTTPS Trunk. As always, once the wizard has completed, you will need to activate the configuration to make your changes come to life. We hope that by now, you might be mumbling the word "activation" in your sleep.
What happens when you add a trunk?
When you create a trunk, whether it is HTTP or HTTPS, several things occur that you might want to be aware of.
The activation process automatically creates a new website within IIS, the built-in Web Server that is included with every version of Windows Server since the dark ages (actually, Microsoft's first web server was developed in Scotland and released as a free add-on for Windows NT 3.51, but you know what we mean). If you inspect your server after adding a trunk to it, using the IIS Management console, you will discover that it has several websites on it. Before we go on, we need to make this clear once again—do not make any manual changes to the IIS configuration, unless specifically instructed to do so by a Microsoft support document or official representative. UAG can get seriously offended if you meddle in its romantic relationship with IIS, and blow up on you. In fact, even keeping the IIS management console open while a configuration is being activated is risky. Assuming you haven't created multiple trunks yet, you should find three existing websites:
- The Default Website
- A website for your trunk
- The Web Monitor website
The Default website is what we like to refer to as the internal site. It is bound to ports 443, 6001, and 6002, and does most of the administrative work for UAG in the background. The Internal Site also hosts the pages and resources that are used during the authentication process, as well as displaying error pages and the logoff mechanism. It also contains a virtual site that serves as the Portal homepage. The portal home includes the various pages and resources that are used to build the portal homepage with its applications.
The trunk website is named according to the name you selected when running the wizard earlier, and should contain three folders: InternalSite, Scripts, and WhlServerProxy.
The Web Monitor site is typically bound to port 50002, and will allow you to monitor the activity on the portal. It can show you how many users are connected and what they are doing, as well as show warnings about problems in the configuration.
If you click on your Trunk's website, and then click on the ISAPI Filter icon (it's under the IIS group of icons, around the middle), you will see an item named <your portal name>-WhlFilter. This item is where the magic really happens. It's linked to the WhlFilter.dll file, and that DLL (Dynamic Link Library) is how UAG does its work. The filter can interact with data that IIS receives and sends, and manipulate it, and that's how UAG can parse and react to URLs the user types or clicks, and modify the content delivered to them.
In addition to IIS, UAG also configures TMG with rules that will allow it to communicate with users from the outside, and with servers on the inside. At this point, you can already find over 20 access rules that have been created by UAG. Most of these rules will be named publishing rule::custom#<some number>, and you should be able to see that they allow traffic from "localhost" (meaning, from the UAG itself) to Internal. These rules allow UAG to contact important internal servers, like the Active Directory servers. You will also find two rules, from All Network to PublishingRule::Server#001 and PublishingRule::Server#002. One of these rules is for port 80 (your redirect trunk) and another for 443 (your portal trunk).
Another interesting rule you will see is the last Deny rule, which is common to pretty much all firewalls. It basically says that anything not specifically allowed in any of the previous rules it will be denied.
In case we haven't said that enough times already, do not attempt to modify any of the existing rules or configurations in TMG, or add any others, unless specifically instructed by a Microsoft support document or official representative. This is even more dangerous than fiddling with IIS, because you might unknowingly create a rule that is too permissive, thereby exposing your server to hostile parties. Keep in mind that baddies are not only out there, on the web, but can also lurk inside your own company. We've heard of plenty of cases where a company's employee dug around various servers and collected information or implanted back-doors for a rainy day.
You might be asking yourself what to do in case you want to manage your server remotely from the comfort of your desk using Remote Desktop. By default, UAG does not configure TMG for this, although TMG will configure itself if you have used Remote Desktop to install the server.
In this article we took a look at the HTTPS Trunk. We saw how to prepare, create and publish an HTTPS Trunk.
- Microsoft SQL Azure Tools [Article]
- Microsoft Azure Blob Storage [Article]
- Microsoft Forefront UAG Building Blocks [Article]
- Setting up the Microsoft Dynamics GP System [Article]
- 3D Animation Techniques with XNA Game Studio 4.0 [Article]
- Introduction to Cloud Computing in Microsoft Azure [Article]