If you missed the first part in this article series please read Authenticate Guest Users With Collective Software’s Captivate (Part 1).
In the first part of this two part article series on how to create captive portals using the ISA firewall, we saw how you can create a simple captive portal that provided some terms of service information and then after the user agrees to the TOS, a click of an “I agree” button provides access to the Internet.
In this, the second and last article in the series, we’ll up the ante a bit for outbound access through the ISA firewall. This time, we’ll configure the Captivate portal to require users to authenticate with the ISA firewall before being allowed to connect to the Internet.
Authenticate Guest Users with a Form
The first example was nice, but what if you want something a little more comprehensive. How about the ability to authorize Internet use by requiring the user to successfully authenticate to the ISA firewall before Internet access is allowed? That way, you can prevent anonymous users from abusing your Internet link.
The problem is that these guests are not managed clients. You can’t configure them as Firewall or Web proxy clients. And only Web proxy and Firewall client can authenticate with the ISA firewall. Our Guest computers must be configured as SecureNAT clients, who by definition cannot authenticate with the ISA firewall. However, with Captivate, we can request credentials from users and only after users are successfully authenticated will they be granted access to the Internet.
Note that this ability to authorize users is not as secure, nor is it as comprehensive as a true Web proxy or Firewall client connection. With Web proxy and Firewall client authentication, all connections to the Internet are authenticated before the connection is allowed.
However, we can require SecureNAT clients to first log on using a form before allowing them to connect to the Internet. After the SecureNAT clients on the Guest Network log on using the form, they will be allowed to stay connected to the Internet for the number of hours that we designate in Captivate Policy. When the policy timeout is reached, users will need to authenticate again.
Captivate will also log this information in the ISA Firewall’s Web Proxy log, so that you can determine who the user was that logged on with the particular IP address. User can be authenticated against local account contained on the ISA firewall or against Active Directory users accounts (when the ISA firewall is a domain member).
Note that this isn’t what you should consider a comprehensive security solution, since we’re tracking the SecureNAT client’s authorization based on IP address or MAC address. Unlike true authentication, it’s relatively easy to spoof MAC or IP addresses. Hackers have methods that can allow them to spoof these addresses and allow them to use the authorization of another user. However, you have to remember that those users will also need to be able to hack into your wireless or wired network as well. Captivate provides a nice way of keeping problematic anonymous users from abusing your Internet link.
In order to create a solution that will allow SecureNAT users to authenticate to the ISA firewall to be allowed access for the number of hours you when them to have access before authenticating again, you’ll need to do the following:
- Create the Guest Web Listener
- Create the Web Publishing Rule
- Configure Captivate for the Web Publishing Rule
- Create the Firewall Access Rule for Authenticated Clients
- Configure Captivate on the Firewall Access Rule
Create the Guest Web Listener
The first step is to create a Web Listener that uses forms-based authentication. This will allow us to collect credentials from the users on the Guest Network. After creating this Web Listener, we’ll create a Web Publishing Rule that uses this Web Listener.
In the ISA firewall console, click on the Firewall Policy node in the left pane of the console and click the Toolbox tab in the Task Pane. Click the New menu and click Web Listener.
On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener. Since this listener will only be used to collect credentials for the Guest Network, we’ll call it Guest Listener.
Click Next.
Figure 1
On the Client Connection Security page, select the Require SSL secured connection with clients option. This will force the client browsers on the Guest Network to use a secure connection when sending their user name and passwords over the wire.
Click Next.
Figure 2
On the Web Listener IP Addresses page, put a checkmark in the Guest checkbox. This allows connections only from the Guest Network to receive the log on form.
Click Next.
Figure 3
On the Listener SSL Certificates page, select the Use a single certificate for this Web Listener option, then click the Select Certificates button.
In the Select Certificate dialog box, select the certificate that the Web Listener will use. In this example, I used IIS 7 to generate a Web site certificate to use with the Web Listener. The common/subject name on the certificate is guest.msfirewall.org. The clients on the Guest Network will need to be able to resolve this name to the IP address on the Guest Network interface on the ISA firewall. Recall that I used the DNS server on the default Internal Network to host the Host (A) record for guest.msfirewall.org.
Another thing to be aware of is that you should use a commercial certificate for this listener. Since the clients on the Guest Network are unmanaged clients, they aren’t going to trust your private CA. I suppose you could require them to install your private CAs certificate, but that’s probably not a good idea from a security viewpoint.
Figure 4
After you select the certificate, click Next.
Figure 5
On the Authentication Settings page, select the HTML Form Authentication option from the Select how clients will provide credentials to ISA Server drop down list. Select the Windows (Active Directory) option from the Select how ISA Server will validate client credentials options. This option allows the ISA firewall to authenticate using either Active Directory or local accounts configured on the firewall.
Click Next.
Figure 6
We’re not concerned with single sign-on in the example, so make no changes on this page and click Next.
Figure 7
Click Finish on the Completing the New Web Listener Wizard page.
Figure 8
Create the Web Publishing Rule
Now that we have the Web Listener configured, we can use that Web Listener on the Web Publishing Rule that will intercept the users outbound connection and allow authentication using the form.
In the ISA firewall console, click the Firewall Policy node in the left pane of the console and then click the Tasks tab in the Task Pane. Click the Publish Web Sites link.
On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the rule in the Web publishing rule name text box. In this example, we’ll name the rule Guest Auth Rule and click Next.
Figure 9
On the Select Rule Action page, select the Allow option and click Next.
Figure 10
On the Publishing Type page, select the Publish a single Web site or load balancer option and click Next.
Figure 11
On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm option and click Next.
Figure 12
Now here’s where things get interesting. On the Internal Publishing Details page, put a bogus entry in the Internal site name text box. The reason for this is that we’re not using this Web Publishing Rule to publish a real server. The purpose of this rule is to allow the form to be presented to the user on the Guest Network. After the user authenticates with the ISA firewall, the Captivate Filter will automatically redirect the user to the URL he requested.
In the Internal site name text box we’ll enter Don’t-Care. Then we’ll put a checkmark in the Use a computer name or IP address to connect to the published server and enter the IP address of the NIC connected to the Guest Network. While this isn’t technically required, it will improve performance because the ISA firewall won’t waste time trying to resolve the name in the Internal site name text box.
Click Next.
Figure 13
Make no changes on the Internal Publishing Details page. Again, we don’t need to configuring anything here because we’re not actually publishing anything. We’re just making it possible for the form to be displayed.
Figure 14
On the Public Name Details page, make sure that the This domain name (type below) option is selected from the Accept requests for drop down list. In the Public name text box, enter the name that is the common/subject name on the Web site certificate bound to the Web Listener.
In this example the common/subject name on the certificate is guest.msfirewall.org, so we’ll enter that into the Public name text box.
Click Next.
Figure 15
On the Select Web Listener page, select the Guest Listener entry from the Web listener drop down list. Click Next.
Figure 16
On the Authentication Delegation page, select the No delegation, and client cannot authenticate directly. Since we’re not actually publishing a Web site, there’s no reason to delegate or authenticate with the non-existent server.
Click Next.
Figure 17
On the User Sets page, accept the default of All Authenticated Users and click Next.
Figure 18
Click Finish on the Completing the New Web Publishing Rule page. Note that we don’t need to use the Test Rule button, since there isn’t a server, we know that the rule will fail.
Figure 19
Configure Captivate for the Web Publishing Rule
Now we need to configure Captivate on this Web Publishing Rule. First, put checkmarks in the Enforce Captivate policy on this rule and Use different settings for this rule checkbox. Actually, you don’t need to put a checkmark in the Use different settings for this rule checkbox if you want to use the default Captivate policy.
In this example I want all users to authenticate at least once a day, at 8AM or afterwards. In addition, after the first log on, I want them to reauthenticate every 8 hours. So I configure the Captivate settings as seen in the figure below to enable these settings.
The Track user name instead of IP when known to ISA doesn’t apply to the SecureNAT scenario we’re using here, so we’ll leave that checkbox unchecked. And we’ll put a checkmark in the Track Physical (MAC) address instead of IP address setting, so that we can use a short TTL on our DHCP addresses.
Figure 20
Now you need to put a checkmark in the Change Advanced Settings checkbox and click the Edit button to open the Lua Script Editor. Find the LogOdbc.lua script in the C:\Program Files\Microsoft ISA Server\Collective Software\Captivate\lua\examples folder and open it in Notepad. Copy the entire contents of the script to the clipboard and paste it into the Lua Script Editor. This allows Captivate to log the user request in the Web Proxy log so that you can trace that user’s IP address and follow the user’s activity in the log file if you wish. It also can enable logging to a SQL database.
If you’re not logging to a SQL database, make sure to comment out the LogAuthorization(originalUrl) line by putting two dashes in front of that line, as seen in the figure below.
Figure 21
Click Save in the script editor and click OK in the Web Publishing Rule’s dialog box.
Create the Firewall Access Rule for Authenticated Clients
With the Web Listener in place to accept the credentials, the next step is to create an Access Rule that will allow the authenticated users outbound access for the protocols we want them to have access to.
However, if you want to allow access to protocol other than HTTP and HTTPS, then you’ll need to bind the Captivate filter to those protocols. To do that, click the Toolbox tab in the Task Pane and then double click the protocol that you want Captivate to control. In this example, we’ll create a rule that allows HTTP/HTTPS/SMTP and POP3. So we need to enable the Captivate filter for these protocol. Click the Parameters tab and then put a checkmark in the Captivate for ISA Server checkbox and click OK. Do that for both the protocols.
Figure 22
Figure 23
Note that binding the filter will not have any effect on Firewall and Web Proxy clients on other networks. The reason for this is that when the Captivate filter gets called for a new connection, it look at what the policy rule is matched. If it’s no a Captivate-enabled rule, then the connection immediately passes. On the other hand, if the request matches a rule with the Captivate filter enabled, then the IP address or MAC address information is checked to see if that address is authorized by Captivate, and if so, the connection is passed through the ISA firewall.
Now let’s create the Access Rule. Click the Tasks tab in the Task Pane and then click the Create Access Rule link. In the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access rule name text box. In this example we’ll name the rule Guest POP3/SMTP/HTTP/HTTPS.
Click Next.
Figure 24
On the Rule Action page, select the Allow option and click Next.
Figure 25
On the Protocols page, select the Selected protocols option from the This rule applies to drop down list. Then click the Add button to add the HTTP, HTTPS, POP3 and SMTP protocols.
Click Next.
Figure 26
On the Access Rule Sources page, click the Add button to add the Guest Network.
Click Next.
Figure 27
On the Access Rule Destinations page, click the Add button and add the External Network.
Click Next.
Figure 28
On the User Sets page, click the Add button and add All Users.
Figure 29
On the Completing the New Access Rule Wizard page, click Finish.
Figure 30
Configure Captivate for the Firewall Rule
Now that we have our Access Rule, we need to configure Captivate for the rule so that the Captivate filter is invoked for connections that match the characteristics described in the rule.
Double click the new Access Rule and click the Captivate tab. Put a checkmark in the Enforce Captivate policy on this rule. Put a checkmark in the Use different settings for this rule and change the parameters to those that you want for the rule. Put a checkmark in the Track Physical (MAC) address instead of IP address checkbox to track the MAC addresses for your on-subnet wireless clients.
Put a checkmark in the Change Advanced Settings checkbox and click the Edit button to open the Lua Script Editor.
Now open Windows Explorer and go to the C:\Program Files\Microsoft ISA Server\Collective Software\Captivate\lua\examples folder and open the Authenticate.lua file in Notepad. Copy the entire text of the file and paste it into the Lua script editor.
Click Save in the Lua Script Editor and click OK in the Properties dialog box for the rule.
Figure 31
Click Apply in the ISA firewall console to save the changes to the firewall configuration.
At this point our firewall policy should look like this:
Figure 32
Test the Solution
Before we test the solution, let’s run down our client requirement checklist and make sure our clients are compatible with the solution:
- In order for MAC address filtering to work, the clients must use the Guest NIC on the ISA firewall as their default gateway. There can’t be any routers between the clients and the ISA firewall’s Guest NIC
- The clients must be able to resolve the common/subject name on the certificate bound to the Web Listener we’re using for the clients’ access from the Guest Network. In this example, the common/subject name on the certificate is guest.msfirewall.org and there is a DNS entry that resolves this to 192.168.100.1.
- The clients should not have browser settings enabled for the Web Proxy client. If you have a wpad entry on the DNS server that you’re using to support this solution, you have to make sure that the DNS server that the Guest Network users use is not that DNS server. The reason for this is that the default browser configuration for Internet Explorer is to autodetect. If this default setting is enabled, the clients will use the wpad entry in DNS and the SecureNAT/Captivate solution will fail.
- Client machines need to trust the certificate presented by the Web Listener. This means that you’ll need to get a commercial certificate, since the clients on the Guest Network aren’t going to trust your internal, private CA
- After the client has authenticated, the clients IP address will be authorized for the entire period Captivate is configured to allow the connection until reauthentication is required. The sessions from the SecureNAT clients are not reauthenticated until the timeout configured in the filter is triggered. Unlikely Web Proxy and Firewall clients, each session is not authenticated.
Now let’s see what happens. I open up the browser and instead of getting the browser’s home page, I’m redirected to the log on form, as seen in the figure below. I’ll enter my credentials and click Log On.
Figure 33
After authenticating, you’ll see the dialog box informing you that you’re going to an unsecure page. That’s fine, since my home page isn’t to a secure site.
Figure 34
Bam! I get to the log on page for my Hotmail account.
Figure 35
Checking the firewall’s log files in the log viewer, you can see the authenticated connection. Notice that even though the connection failed to the Guest Auth Rule, we got what we needed, which is the user name and IP address used by the user.
Figure 36
What About Non-Web Protocol Connections?
Now this works fine for HTTP and HTTPS connections made through your Web browser. But what would happen if the user opens Outlook Express or some other mail application and tries to use SMTP and POP3? Would the SMTP and POP3 connections work?
It depends. If the user opened the Web browser and authenticated with the ISA firewall before trying to use the mail application, then the connection would work. However, if the user opened the mail application before opening the Web browser and authenticating, then the connection attempt would fail. The failure is due to fact that the user hasn’t authenticated yet with the ISA firewall, so the Captivate filter blocks the connection.
The solution to this is easy. In fact, for seasoned travelers, they already know that they need to open their Web browsers to “do something” with a captive portal before being allowed to access the Internet. So, all you need to do is tell your users to open their browsers and do what they’re supposed to do on the portal site. No problems.
Summary
In this two part article series, we examined how to use Collective Software’s Captivate filter to capture outbound connections from a Guest Network. We examined two scenarios – one scenario where users are presented with a Information Page, and must click a button to indicate that they agree with what’s on the Information Page before being allowed to the Internet. In the second scenario, we put together a solution that requires users to authenticate before being allowed to connect to the Internet. The Captivate filter was easy to install and easy to configure. If you’re looking into a solution for your “anonymous” clients, Captivate is a great, cost-effective solution. And if you’re interested in a more sophisticated solution, such as creating a captive portal like those you see in hotel rooms and other hot spots, Collective Software has consultants who would be happy to work with you to put such a solution together using the Captivate filter.
If you missed the first part in this article series please read Authenticate Guest Users With Collective Software’s Captivate (Part 1).
