A Captive Portal to Handle My Needs

Question

I am looking into captive portals for my organization. I see a lot of them out there that will allow a user to pass once they a.)enter credentials or b.)pay money. What I'm looking for is a bit different. Let me go into some basics about my system, I am running a windows based network using active directory and an internal DNS. I have an intranet in which our employees use daily and it uses the person's Windows credentials to authenticate them on the system.

The employees have to enter time daily, and if they don't then I would like to have a captive portal redirect them to their time entry page and not let them out into the vast internet world until their time is entered.

I am a developer so I can write a script that returns a True or False to the system, but what I need is a system that can interact with AD logons and that can run this script once a user requests access outside out network.

EDIT: I accepted an answer as the answer to my question, however, after looking into the coding for the sockets based method I do not have the time.

as a workaround, I have found that my firewall has a customizable disclaimer page that allows javascript. I will query a webservice to see if time is entered then trigger the disclaimer page's "Allow" function, otherwise i will redirect to the time entry page. seems like a simple enough solution, the only issue is if the person keeps their browser session open overnight.

Answer 1

Well nowadays I only really code in .NET, some of the OSS may have better ideas.

I can't see anyway of doing this without using a proxy, preferable a transparent proxy server on the gateway. There must have people who have written such things. Of course every commercial wifi hotspot has one, but you presumably want one that runs on a sever not a device.

I have no real idea about this but it is something I have thought about in the past.

You may be able to find a router/firewall box that has the feature. Microsoft IAS my have a plug in that does this (it is unlikely to be cheap). A brief look on google did not turn up much in the way of other software that does this.

Wingate - Might do it, I couldn't figure it out

Otherwise you could code a transparent proxy application (which means, unless you write embedded code, you'll need to use the app server as the default gateway), or just an ordinary proxy if you can lock down users browser proxy settings. I guess coding this is possibly not a easy option! But it is possible. You could even use IIS and ASP.NET.

iisproxy is a proxy implemeted as an IIS ISAPI filter with source code. I suspect this is in C or C++.

On Codeplex is a revrse proxy code sample. You could change it and extend to a full proxy.

You might to be able to do the whole thing with sockets and get out of the application layer altogether. This might make life simpler, so I expect there is a reason it can't be done like this! Have the sockets based proxy redirect to the non-compliant users to the time recording app, when they have filled in their time sheet just pass all the data beween the sockets transparently.

I'd be interested in what you or anyone comes up with because I've always wanted an AUP to appear with a continue box once a day to users in our office. Better still it could list how much time the user spent yesterday on face book etc. if the proxy collected that info. Just enough to alter people's behaviour I think. In fact there are loads of useful things that can be done with an easy to alter or extensible HTTP proxy.

Answer 2

DNS Redirector is a captive portal product where you can develop your own welcome/blocked pages in HTML/ASP/whatever. Since your server is already running Windows why not use IIS and ASP for this.

Answer 3

Christopher Edwards is more or less right. A Captive portal is basically a firewall that transparently forwards all connections to a local Web Server asking for user authentication. After successful authentication the firewall rules are reconfigured for the IP of the authenticated user so he/she can access Internet or other network.

You could setup your own Captive portal by means of scripts and a web server or a proxy, but what is mandatory is that physically all the network traffic crosses the machine acting as firewall.

I have experience with an OSS distribution called m0n0wall that is based on a BSD distribution and it can be embedded directly on dedicated hardware or be installed on any PC. This distribution, though OSS, is really professional and offers basically the same or more functinality than any commercial FW appliance (i.e. Watchguard products, or Cisco Products). It offers a web administration interface to completly administer the firewall.

The only issue if you decide to go this way is that m0n0wall Captive portal has only two ways of authentication: local user database list or external Radius Server. In your case what you need is to setup an external Radius server that integrates in the AD authentication services. Here is an example of how to do it.

Answer 4

This how it works. You need:

• an iptable common firewall,
• an open router firmware like dd-wrt which has more options to support hotspot
• server like apache
• dhcp3-server as DHCP server
• bind9 as DNS server, so users don't have to configure their computer network configuration manually when they are connected to the hotspot
• PHP or other language to write the server side script of your choice.

You need to mark packets which you don't intend redirecting to the internet but to a landing page when the user gets verified at the landing page his or her IP will be removed from the list so that he can browse freely or else if he tries to browse his packets will be marked and that what you will use to identify him. I suggest you use linux for this because of the iptables stuff.

This is how it works:

1. Every user which is connected to the wireless hotspot are connected to the internet through a gateway.
2. The gateway itself acts as a router and a firewall (and probably also acts as a portal webserver just like in this experiment).
3. Every HTTP data packet destined to the internet from unauthenticated users are "marked" with a special code by the firewall so it can be intercepted (redirected) to the portal webserver.
4. Portal webserver serves an authentication web page to the user transparently and identify the computer used by them.
5. The user accepts/authenticates themselves with the webserver so their computer identity (in this case their network interface MAC address) are being entered into firewall's whitelist.
6. As long as user's network interfaces are inside the firewall's whitelist, packets sent from them are not marked for intercepting. The packets are then forwarded by the router to the internet without being intercepted again to the web portal.