Using Captive Portal AND the Active Directory Logon Script

As we well know, using these two items together is not supported. The captive portal ALWAYS blocks the website and forces authentication even if the user has already been authenticated through the ADLS.

So, I set out tonight to find out how to bypass that. And I think I have come up with a clever way to do it. I'd like to run it by you guys and see if any people with more knowledge of untangle can point out where there might be problems with this. SO far it appears to work properly.

I created two new .php files in the /usr/shared/untangle/web/cpd folder.

One called opencpd.php :

Code:

---

<?php
$ip = $_SERVER['REMOTE_ADDR'];
system("/usr/bin/sudo ipset -A cpd-ipv4-authenticated $ip");
system("/usr/bin/sudo ipset -D cpd-ipv4-expired $ip");
?>

---

A second called closecpd.php :

Code:

---

<?php
$ip = $_SERVER['REMOTE_ADDR'];
system("/usr/bin/sudo ipset -D cpd-ipv4-authenticated $ip");
?>

---

I then added the following lines to the /etc/sudoers file with visudo:

Code:

---

www-data  ALL=NOPASSWD: /usr/sbin/ipset

---

I then added the following lines to the AD login script:

Code:

---

  command2 = "http://" + ServerName + "/cpd/opencpd.php"
  AJAX.Open "GET", command2
  AJAX.Send ""

---

And I created a AD logoff script:

Code:

---

'Handle or Ignore all errors
On Error Resume Next

If WScript.Arguments.Count = 1 Then
        ServerName = WScript.Arguments.Item(0)
Else
        ServerName = "10.0.5.250"
End If

'WScript.Echo "ServerName is:"
'WScript.Echo ServerName


  Set AJAX = CreateObject("MSXML2.ServerXMLHTTP")
  command2 = "http://" + ServerName + "/cpd/closecpd.php"
  'WScript.Echo command
  AJAX.Open "GET", command2
  AJAX.Send ""

---

I discovered that the Captive Portal places an entry in iptables using ipset that causes an IP address to bypass the captive portal login. It will remove the entry when the session times out or the user logs out.

So, I granted apache and my PHP scripts the ability to run the ipset command as root using the sudoers file.

Then, I created those two scripts to add an entry using ipset, and to remove an entry using ipset. When the script is called it identifies the IP address of the client and adds an entry for that client to the ipset table associated with captive portal so that it can bypass the portal login.

I then modified the login script to call the opencpd.php script and bypass the portal, and I created the logoff script to call closecpd.php to activate the portal again.

By using this method I am able to get my users authenticated with the AD login script and they never see a captive portal login. However, users who are not on the domain and do not run the AD login script see the captive portal to authenticate.

An extra rack can than be added in policy manager to route all unauthenticated users through a web filter that blocks all access. Forcing everyone to authenticate, either automatically with the login script for computers on the domain, or manually with the captive portal for those that like to come and go with their laptops and other devices.

Reporting is handled normally, and users are correctly identified.

Anybody see any problems with this?

Good to know, i wasn't aware you couldn't use both.

How is this solution working for you? I've been looking to do exactly this, but don't have the neccesary skill ;)

Untangle team, any chance of seeing this (or something similar) folded into the product?

Thanks,
Tim

I'm looking into a different strategy - use the login script my admin and lab subnet, and captive portal for my student and wireless subnets. There will be no capture rule in captive portal for most users that log in to the domain, and those few that do via wireless will just have to deal with the capture page.

I am also curious to know if this has been incorporated into the default distribution. Also, does it continue to work well for those that have implemented it?

It has been.
I dont remember the URL, but you can logout by hitting it.

So Just to be clear. I can just install the rack item for captive portal on my UT box and without any further effort on my part, those people that aren't connected through the AD script will be required to log in through the captive portal, and those that ARE connected through the AD script will never see a difference? If so you guys are awesome! If not you're still awesome but I'm wearing a sad face.

Thanks for your help,

BOFH

Sorry, I was talking about the logoff script.
There is still no logon script to my knowledge.

btw, just glancing at the code above I can tell you it wont work. It will appear to work but the ipset data will be inconsistent with the database.
I guess that isn't the end of the world, but I wouldn't be surprised if you get weird side effects.

Quote:

---

Originally Posted by BOFH

So Just to be clear. I can just install the rack item for captive portal on my UT box and without any further effort on my part, those people that aren't connected through the AD script will be required to log in through the captive portal, and those that ARE connected through the AD script will never see a difference?

---

you'll need to set Captive Portal to only capture those who you need to (eg NOT the people running the ADLS) and set it up to authenticate against AD, that should be it.

I don't understand the script; this will allow, that anybody could call this opencpd.php directly, without logging in and would then prevent captive page?

I must've been unsubscribed to the thread. I'm glad there is some renewed interest here.

I will concur that the solution I listed in the initial post has not been successful. It does work, but for some reason, at random times the captive portal will pop up on users that are still authenticated through the logon script. I lack a proper understanding of how this is all tied together in untangle and so this truly is a hack.

Dmorris, I am curious if you can provide more details about the database inconsistency. Its been a while now, but I remember also looking at the database and finding where the entries were for captive portal. Are you suggesting that if the script is enhanced to also delete the necessary items from the database that this might be successful?

@Frust, yes, anybody can call the script and disable the captive portal page. However, there are two reasons this is unimportant to me. First, there isn't much chance any user on my network is going to have enough skill to figure out the URL. Secondly, even if they do, with the proper policies you are able to block any "unauthenticated" traffic. So, just because they disable the captive portal does not mean they can just do whatever they want. It just means that they have failed to authenticate and the traffic can be handled accordingly.

For quite some time I have disabled the captive portal and given unauthenticated users open, but filtered access to the internet. The idea of forcing people to login who are already authenticated through the AD script is ridiculous and I really hope there is an "official" fix for this problem soon. Until then, no captive portal for me, unless I start hacking again myself.

Hi everybody,

I really was looking for a solution to that subject. Finally I wrote a adautologin.jsp, which does exactly what we all want.

Installation:
--------------
Copy the attachment adautologin.jsp into the folder
/usr/share/untangle/web/adpb

Integration in Active Directory Logon Script:
-----------------------------------------------
Replace 'registration' with 'adautologin.jsp', and remove the action=login parameter:

Code:

---

  command = URL_PREFIX+"://"+ServerName+"/adpb/adautologin.jsp?username="+strUser+"&domain="+strDomain+"&hostname="+strHostname

---

Be aware, that this script does not check any passwords, as it expects that it is executed from the AD login script! So therefore the script might be a potentionally security hole, but this risk you have already if you work with the Active Directory Login Script without Captive Portal, because they also do not pass passwords from the active directory login script.

You can test the feature with the following url directly:
untangleserver/adpb/adautologin.jsp?username=xxxxx&domain=xyz.com&hostname=myworkstation


There is one little dirty hack in the Script, I want point you. Unfortunately the cache object to update the Captive Portal Login Information "assistant" is a private class member of the CPDPhoneBookAssistant object, so we have to access this assistant object by java reflection api.

The script works very stable, and the results are as expected.

Feel free to use it and have fun!

Regards,
Michael

Hi everybody,

unfornately there was a bug in the adautologin.jsp, so the user was not logged in the first time after captive portal session was expired. Find a fixed version attached to this post.

Regards,
mseelig

I made a new solution, which is working perfectly with the current 9.0.1 build of untangle. Please take a look at the following thread:
http://forums.untangle.com/hacks/248...-untangle.html