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.