If you would like to read the next part in this article series please go to Authenticate Guest Users With Collective Software’s Captivate (Part 2). 

I was recently looking for a solution to the problem of anonymous client access on Guest wireless networks. As you might know, the ISA firewall is an ideal solution for hosting guest networks. These guest networks are used by people who are visiting your facility. You want to give your guests access to the Internet, but you don’t want them connected to your corporate network. You never know what worms, viruses and other malicious traffic they might generate. Even if you use NAP for server and domain isolation, you still want to keep these clients off your corpnet, if for no other reason than to reduce the impact these unmanaged clients might have on network performance.

In fact, I’ve done an article on how to configure a wireless DMZ using the ISA firewall. You can find that article here, if you want more detailed information on how to create a wireless guest network.

However, that solution does not allow us to authenticate our guest users. The reason for this is that we do not manage the machines on the guest network, so we cannot force the users to install the Firewall Client or have them configure their machines as Web Proxy clients. We need a completely transparent solution, which means configuring the guests as SecureNAT clients.

The problem is that SecureNAT clients cannot authenticate with the ISA firewall, and thus, we have to allow all connections from the guest network to be anonymous. A better solution would be to require that users authenticate with the ISA firewall before being allowed to connect to the Internet. This would provide me user information, match it to the user’s IP address, and prevent anonymous users from connecting through the ISA firewall. So, even if someone was able to break into the WAP, they still wouldn’t be able to connect to the Internet.

But how to do this?

This is when I ran into Collective Software’s Captivate filter. This filter allows you to create a captive portal on the ISA firewall that will intercept the user’s initial request for Internet resources. And then after the user performs a certain act in the portal (such as pressing a button to indicate he agrees with terms of use or authenticates with the ISA firewall), the user is allowed to access the Internet for a period of time you configure in the Captivate Filter.

The Captivate solution sounded interesting, so I decided to put a test network together to see how it works before deploying it at my client’s site. The figure below shows my lab network.

Figure 1

The ISA firewall on this network has three NICs:

• The Guest Network NIC. This is on network ID 192.168.100.1 and the interface IP address is 192.168.100.1 Network Rules: Guest->Internal = Route. Guest->External = NAT
• The Internal Network NIC. This is on network ID 10.0.0.0/24 and the interface IP address is 10.0.0.1
• The External Network NIC

A DNS server was installed on the Internal Network so that name resolution for the portal page could be resolved. A DNS record for guest.msfirewall.org was created on the DNS server that resolves that name to 192.168.100.1  I created an Access Rule to allow DNS queries from Guest Network hosts to the DNS server on the Internal Network. This rule is exempted from Captivate polices.

A Certificate Server was installed on the Internal Network. This is required because we need to generate a certificate for the secure portal page (so credentials are not sent in clear text). The common/subject name on the certificate is guest.msfirewall.org. The CA certificate of the issuing CA was installed on the client that will connect from the Guest Network.

Note that in a production environment, you will need to use a commercial certificate, since the clients on the guest network will not recognize the CA on your private network, and thus will not trust them.

I didn’t want to put a separate DHCP server on the guest network, so I configured the ISA firewall to be a DHCP relay agent and configured it to use the DHCP server already on the Internal network. Then I created a scope on that DHCP server with addresses valid on the Guest Network. In a production network, you’d typically have your WAP handle the DHCP duties. I then created the Access Rules on the ISA firewall that are necessary to support the on-box DHCP relay agent.

Installing Captivate

The first step is to download and install the Captivate software. You can download Captivate at the Collective Software website. Double click the file and you’ll see the Welcome to the Captivate 1.x Setup Wizard. For this demonstration, I’m using version 1.0.2. Note that during the installation the firewall service will be stopped and restarted. Also, make sure the ISA firewall console is closed when you install Captivate.

Click Next.

Figure 2

Put a checkmark in the I accept the terms in the License Agreement checkbox and click Next.

Figure 3

On the Choose Setup Type page, click the Complete button and click Next.

Figure 4

Click the Install button on the Ready to Install page.

Figure 5

The progress bar let’s you know about the components being installed.

Figure 6

Click Finish on the Completing the Captivate Setup Wizard page.

Figure 7

The installation went without a hitch. That’s a great sign, since I often find that installing third party add-ins to the ISA firewall have peculiarities. Not so for Captivate.

Configuring Captivate

Now that we have Captivate installed, we need to do some basic configuration of the filter. In the ISA firewall console, go to the Add-ins node in the last pane of the console, then click the Web Filters tab. On the Web Filters tab, right click the Captivate entry and click Properties.

Figure 8

This brings up  the Captivate for ISA Server Properties dialog box. This is where you can set the default Captivate policy. Note that you have complete control over changing this policy on a per rule basis, but if you want to save a little time and standardize you Captivate policy, you can set it here.

The options are:

When last authorization was more than H M ago. This policy tells Captivate that the user needs to be authorized every x Hours and x Minutes. For example, if you want to make sure that users authenticate every 8 hours, you would put 8 in the H text box and 0 in the M text box.

Every day at (or after) This policy allows you to set a time each day that users must authenticate. Note that you can use both the When last authorization was more than H M ago and the Every day at (or after) option, so that you can make sure that all users authenticate at 8AM and then at least every 8 hours after that.

By default, Captivate tracks agreements on a per IP address basis. If your have an Access Rule or a Web Publishing Rule that requires authentication, then you can select the Track user name instead of IP when known to ISA. This way, if a user logs in from several computers, they will not have to go through the agreement process several times. If you choose this option but the user names are not available, then IP address will be tracked instead.

NOTE:
The Track user name instead of IP when known to ISA option doesn’t apply to the scenarios discussed in this article series, where we are tracking SecureNAT clients on a Guest wireless network. The Track user name instead of IP when known to ISA option is useful if you want to force users on networks where you do enforce Web Proxy or Firewall client authentication, but want to insure that those users are forced into the portal on a periodic basis.

If users are configured to use the ISA firewall as their default gateway, the ISA firewall should be able to track the MAC addresses for all connected computers. You can select the Track Physical (MAC) address instead of IP address option if your network recycles IP addresses frequently, such as in a hot-spot configuration. This option should not be used if there is a router interposed between the clients and the ISA firewall, since in that scenario the ISA firewall will only see the MAC address of the router closest to the ISA firewall’s interface receiving the connections.

The Change Advanced Settings checkbox enables the Edit button. When you click the Edit button, it will open a LUA Script Editor, where you can paste in script contents that enhance the functionality of the Captivate filter. We’ll see examples of what functionality you can add with this option later in this article.

Figure 9

Setting up an Agreement Page

Now let’s look at our first scenario. In this example, we have our wireless DMZ network from which we allow guests to connect to the Internet. The first thing I did was create a simple Access Rule that allows all computers on the Guest Network to connect to the Internet using a NAT relationship. This rule applies to all users.

After creating the Access Rule, right click it and click on the Captivate tab. First, we need to put a checkmark in the Enforce Captivate policy on this rule. Then you can put a checkmark in the Use different settings for this rule checkbox if you want to use settings that differ from the default policy that we configured earlier. In this case, I’ll configure the rule to require that all users authenticate once a day, at 8AM (or afterwards, if the logged in after 8AM).

Figure 10

Click the Apply button in the ISA firewall console to apply the changes. That’s it! Now lets go to a client on the Guest network and see what happens when we open the browser.

As you can see, a form appears with some text informing the user that this is a connection for authorized users only. It also informs the users that the traffic may be inspected and their activities logged. Then they have to click the Agree button to get to the Internet.

Note that you can easily customize this form so that you can change the background, graphics and text to meet your preferences or requirements. The details of the HTML and CSS pages you can use to customize things are contained in the Captivate user guide.

Figure 11

Yay! The connection to the Internet worked. Now if I stay on this computer for another 8 hours, the form will appear again and I’ll have to click the I agree button.

Figure 12

Now let’s say that you want to track when users click the button. You can have that information saved to the special Captivate Event Log that can be viewed in the Windows Server Event Viewer.

In order to do that, we need to take advantage of the LUA scripts created for Captivate. You can find this in the \Program Files\Microsoft ISA Server\Collective Software\Captivate\lua\examples folder. Open the EventLog.lua script in notepad and copy the entire contents of the folder to the clipboard.

Figure 13

Now open the Properties dialog box of the Access Rule and click the Captivate tab. Click the Edit button after putting a checkmark in the Change Advanced Settings checkbox. Paste the contents of the script into the Lua Script Editor. Click Save in the editor and then click OK in the Properties dialog box for the rule. Then click Apply in the ISA firewall console to save the changes.

Figure 14

Here’s an example of what you’ll see in the log file.

Figure 15

Summary

In this, part one of our two part article series on how to create a captive portal to control access out of a guest network, we saw how to use Collective Software’s Captivate filter to present a simple Agreement page before allowing users to connect to the Internet. In the second part of this series, we’ll see how to create a captive portal that requires users to authenticate before being allowed to connect to the Internet.

If you would like to read the next part in this article series please go to Authenticate Guest Users With Collective Software’s Captivate (Part 2).