Seeing as how Dinesh is the captive portal guru, I figured I'd directly
solicit his opinion... SSL isn't as much a need when you are authenticating
people for hotspot access perhaps, but in this case, it sure would help.
More thoughts below...
> -----Original Message-----
> From: Chris Buechler [mailto:cbuechler at gmail dot com]
> Sent: Saturday, September 11, 2004 3:38 PM
> To: m0n0wall at lists dot m0n0 dot ch
> Subject: Re: [m0n0wall] External Authentication
> On Sat, 11 Sep 2004 15:26:06 -0700, Mitch (WebCob)
> <mitch at webcob dot com> wrote:
> > Sorry I'm late to the game... I missed much of the thread - but
> in summary,
> > are you thinking of turning mono around? Using Radius authentication
> > (through SSL) to control ingress to you application instead of egress?
> > Not sure if that was your original idea, but I think that's a
> GREAT one...
> > could help me in a current project as well - we have to
> "expose" a windows
> > server for remote access - using the Radius server inbound to
> the central
> > server could provide us with the required session logging and
> stats as well
> > as a second level of security for the windows service.
> > I've heard of people trying to set up mono to use the NT radius
> service as
> > it's auth source - is this the solution? Then the users would be able to
> > auth using the same password as they use on their domain login.
> > If I'm completely confusing or perverting your original idea,
> smack me - but
> > is this what you were thinking? Is it possible?
> That was the original idea. You could theoretically use RADIUS on
> your Windows DC, NT or AD, to authenticate users on the m0n0wall, and
> then open up a port. Captive portal doesn't support SSL right now
> though, so it would have to pass the credentials over the net in clear
> text. And you might have to do a little hacking on captive portal to
> keep it from opening all ports to authenticated users, though firewall
> rules may suffice.
> When captive portal supports SSL, this would make a great solution if
> it could be set up appropriately. It might be possible now, but I'd
> rather see Windows ports open to the internet than domain passwords
> being passed over the internet in clear text.
> Along those lines, since I understand this is an internal-only
> application with only employees as users, why not make them connect
> via VPN first?
VPN won't work for me... not sure about the other guy.... mobile
workforce... potentially hundred of users... cost of maintaining a VPN
solution would be big - support could be bigger - and IPSec doesn't work
everywhere (certain hotels, etc. don't properly support passthrough.)
The goal here is to allow selective access to THEORETICALLY secure services
without opening them to the world JUST IN CASE.
That said, I have a couple of questions as to how this would work... let's
say we are using this to allow access to a service (not web) like smtp, or
exchange, or ?
How will the session be maintained for the remote user?
- remote user opens their browser and goes to
- if SSL is enabled / available, captive portal redirects user to the
- user authenticates, starting radius accounting
- IF user was originally asking for an http:// link, re-redirect them to it?
(PRESERVE EXISTING FUNCTION?) or would it be easier to simply have a config
switch to force https:// auth and not respond to http:// auth?
- User can now access other ports on the previously protected network...
- eventually a timeout or logout action could close the ports
SO - here is my quandry... how does the user maintain their session? By
keeping the https:// login page option (which could have some sort of
meta-refresh to provide a "keep-alive"?)
I sure see the value in this - just not sure how hard it would be to do.
Dinesh? Thanks man!