Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 7)

By /

If you would like to read the other parts in this article series please go to:

Introduction

Here we go again! This is part 7 of our (seemingly never-ending) series on Web and Server Publishing Rules. We will continue this week with our discussion on the details of the Web Publishing Rule that we created several installments ago. As I’ve mentioned in the past, it’s very easy to create a Web Publishing Rule, but if you want it to do everything you need it to do, you might have to dig into the Properties of that Web Publishing Rule and do some “fine tuning” to make it dance and sing. Let’s pick up today with the options that you have available to you on the Authentication tab.

Authentication tab

As you can see from the figure below, there are four types of authentication that you can choose from. These are:

  • No Authentication. No authentication is just that – no authentication of any kind. If you don’t want or need your users to authenticate with the TMG firewall before being forwarded to the published site, then you would select this option. Keep in mind, however, that you can always enable authentication at the web site itself. This controls only whether or not the TMG firewall will do the authentication before the client is allowed to access the site.
  • HTTP Authentication. HTTP authentication allows you to access one of three types of HTTP authentication methods: Basic, digest or integrated. If you choose to enable HTTP authentication, make sure that you’re using SSL for the connection because these authentication methods are easy to “sniff” on the wire and intruders might be able to gain access to passwords over an unencrypted channel.
  • SSL Client Certificate Authentication. You should use this option if you want users to take advantage of client certificate authentication. This is a secure form of authentication that requires that the users have a certificate that you issue in order to access the web site through the TMG firewall.
  • HTML Form Authentication. HTML forms based authentication presents a form to the user and the user enters his or her authentication information into the form. This is one of the most versatile methods of authentication and it supports a number of authentication protocols on the back end. However, you must make sure that you deliver the form to your users over a secure SSL channel, because the initial authentication credentials are completely in the clear. Any protocol analyzer will be able to easily read the credentials over an unencrypted session.

As you can see in the figure below, if you select No Authentication you don’t have any options, nor should you.


Figure 1

If you select the HTML Form Authentication option, you have a number of additional choices:

  • Collect additional delegation credentials in the form. If you select this option, the logon form will include additional fields for user credentials. The TMG firewall will use the credentials for authentication to published servers.
  • Windows (Active Directory). This option uses integrated Windows authentication (either NTLM or Kerberos) to authenticate the incoming connection.
  • LDAP (Active Directory). This option takes advantage of LDAP to authenticate the user. You can use this option if you want to take advantage of Active Directory user accounts but you don’t want to make the TMG firewall a member of your domain. While domain membership for the TMG firewall is highly recommended from a security perspective, some organizations do not and will not appreciate this fact, and have their own reasons for not joining the TMG firewall to the domain. In that case, you are still able to leverage your Active Directory accounts by using the LDAP option.
  • RADIUS. This option enables you to take advantage of a RADIUS server for authentication. Similar to the LDAP option, you can use RADIUS to authenticate users when you cannot make the TMG firewall a member of your Active Directory domain for some reason. RADIUS also allows you to leverage non-Active Directory authentication repositories.
  • RADIUS OTP. The RADIUS OTP option allows you to take advantage of RADIUS and two factor authentication. The OTP option enables you to use any OAuth capable device to enable the second factor for authentication.
  • RSA SecurID. This option enables you to authenticate incoming connections by using the RSA SecurID protocol and devices.


Figure 2

If you choose a method that doesn’t take advantage of Active Directory, you will need to configure the TMG firewall so that it knows where to look for the accounts. In this case, you would click the Configure Validation Servers button and that will bring up the Authentication Servers dialog box. In the Authentication Servers dialog box, you will see two tabs labeled as follows:

  • RADIUS Servers. On the RADIUS Servers tab, you configure the names of the RADIUS servers that the TMG firewall will use to access the user account information.
  • LDAP Servers. On the LDAP Servers tab, you configure the names of the LDAP servers the TMG firewall will use to access the user accounts that the TMG firewall needs to authenticate the incoming connections.

Notice, on the LDAP servers tab, that you need to create an LDAP Server Set and then populate the server set with a collection of LDAP servers that will be able to answer the LDAP queries that are sent to them. After you create these LDAP server sets, you then need to define the login expressions that the TMG firewall will use to match the user login settings. These strings will be used by the TMG firewall to determine which LDAP server set should be used to authenticate the incoming connections.


Figure 3

Notice that when you select the HTML Form Authentication option and then enable the Collect additional delegation credentials in the form option, you only have two choices available:

  • RADIUS OTP
  • RSA SecurID

The reason for this is that the additional information the TMG firewall collects is related to the second factor of authentication; given that RADIUS OTP and RSA SecurID are both two-factor authentication methods, this makes sense.


Figure 4

When you select the HTTP Authentication method, you are given the following three options:

  • Basic. Basic authentication is a widely-used method for collecting user name and password information. Basic authentication sends and receives user information as text characters that can be read. Although passwords and user names are encoded, no encryption is used with Basic authentication. The advantage of Basic authentication is that it is supported by almost all HTTP clients. The disadvantage is that Web browsers using Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, an attacker or malicious user could intercept and decode these passwords by using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or an SSL connection.
  • Digest. Digest authentication offers the same features as Basic authentication, but provides a more secure way of transmitting the authentication credentials. This method is not supported by all web browsers, though. If a non-HTTP 1.1 compliant browser requests a file when Digest authentication is enabled, the request will be rejected. Something else to keep in mind is that digest authentication can be used only in Windows domains. Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user’s password stored in AD DS. To allow passwords to be stored in plaintext, you must activate the Store password using the reversible encryption setting on the Account tab of the user in AD DS. Alternatively, you can set group policy to enable this capability. After configuring this setting, you must set a new password to activate this feature because the old password cannot be determined. WDigest, a new form of Digest authentication, is used when Forefront TMG is installed in a Windows Server 2008 domain. WDigest does not require a reversibly encrypted copy of the user password to be stored in AD DS
  • Integrated. Integrated Windows authentication uses the NTLM, Kerberos, and Negotiate authentication mechanisms. These are more secure forms of authentication because the user name and password are hashed before being sent across the network. When you enable NTLM, Kerberos, or Negotiate authentication, the user’s browser proves its knowledge of the password through a cryptographic exchange with your Forefront TMG server, involving hashing.

In general and in actual practice, Basic authentication is the simplest to configure and works well, as long as you make sure that the credentials are always passed over a secure SSL connection. The type of authentication you enable also will depend upon any kind of protocol transition you need to deal with.


Figure 5

Finally, we have the SSL Client Certificate Authentication option. This is the most secure option and it enables users who have been given a client certificate to use that certificate to authenticate to your TMG firewall. Note that the Configure button becomes available if you select the Use a fallback authentication method option. When you click the Configure button, you will be able to select a fallback authentication method that the user can use in the event that the client certificate authentication fails. The three choices look familiar: Basic, Digest and Integrated.


Figure 6

Summary

In this article, part 7 of our Web and Server Publishing Series, we went over the many authentication options that are available to you when you want the TMG firewall to authenticate the connections before allowing the connections to be forwarded to the published Web server. In the next article in this series, we’ll take a look at some advanced SSL settings. See you then! –Deb.

If you would like to read the other parts in this article series please go to:

About The Author

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top