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.
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.
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.
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.
After you select the certificate, click
Next.
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.
We’re not concerned with single sign-on in the example, so make no changes on this page and click
Next.
Click
Finish on the
Completing the New Web Listener Wizard page.
Create the Web Publishing RuleNow 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.
On the
Select Rule Action page, select the
Allow option and click
Next.
On the
Publishing Type page, select the
Publish a single Web site or load balancer option and click
Next.
On the
Server Connection Security page, select the
Use SSL to connect to the published Web server or server farm option and click
Next.
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.
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.
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.
On the
Select Web Listener page, select the
Guest Listener entry from the
Web listener drop down list. Click
Next.
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.
On the
User Sets page, accept the default of
All Authenticated Users and click
Next.
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.
Configure Captivate for the Web Publishing RuleNow 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.
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.
Click
Save in the script editor and click
OK in the Web Publishing Rule’s dialog box.
Create the Firewall Access Rule for Authenticated ClientsWith 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.
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.
On the
Rule Action page, select the
Allow option and click
Next.
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.
On the
Access Rule Sources page, click the
Add button to add the
Guest Network.
Click
Next.
On the
Access Rule Destinations page, click the
Add button and add the
External Network.
Click
Next.
On the
User Sets page, click the
Add button and add
All Users.
On the
Completing the New Access Rule Wizard page, click
Finish.
Configure Captivate for the Firewall RuleNow 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.
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:
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.
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.
Bam! I get to the log on page for my Hotmail account.