AD Connector Script cause 20-30min login time?

[joemailey]

Hi,

New to untangled, Great piece of software so far.
I'm currently testing it, to see if it can replace Trend IMSS Mail scanning and Barracuda Webfilter.

we need to see the user activity, As that is what the Barracuda web filter does.
We need to log user activity.

I've got the AD connector set-up and working.

I then set-up the script in a group policy.
But this morning when users logged in all they got was there Desktop background no icons or anything for about 20-30mins then it worked.

I may add I'm using Desktop Authority to run scripts as well.

I was thinking about adding the script to Desktop Authority for it to run, but after reading this thread AD Connector and Desktop Authority(can't link to it as I am a new poster)

It doesn't sound like such a great idea.

Does anyone have any tips or advice for me to get this to work? and not cause long login time?

[sDaily]

I was curious, I ran into the same problem and other minor issues. Since Barracuda Networks is using Squid for their filter which is under the GPL license. Would they not need to release the source code for those requesting it. They have opened up recently after the Trend Micro lawsuit to become advocates for the Open Source community. Has anyone received a copy of this or made a formal request? If not, why dont we. Thats the whole idea of opensource isnt it?

[dmorris]

I heard about a similar issue recently. I'm not sure of the cause.

Make sure you're running the script in the background - it is not meant to be run in the foreground as it loops forever when the user is logged in to keep untangle up-to-date.

[lschafroth]

I'm kinda hijackingthis thread.

I tested the new script I made for the Mac and it runs in the background and works great.

I did notice though, that the debug screen on the UT server showed me connected even after 20 minutes of killing the update script. Does it determine I am still connected because of the ARP table and just uses the last ip, user info from the script?

I was under the ussumtption it would go away from the debug screen if the script stopped updating the UT box.

Lannie

[dmorris]

Originally Posted by lschafroth

I'm kinda hijackingthis thread.

I tested the new script I made for the Mac and it runs in the background and works great.

I did notice though, that the debug screen on the UT server showed me connected even after 20 minutes of killing the update script. Does it determine I am still connected because of the ARP table and just uses the last ip, user info from the script?

I was under the ussumtption it would go away from the debug screen if the script stopped updating the UT box.

Lannie

It should - I don't know off the top of my head what the timeout is.

[sky-knight]

I think the time out is 30min... so if the script stops updating you have half an hour before the policy doesn't apply.

And, if you deployed the script using group policy like you should have, and you got long logins? You have a DNS issue with your domain you need to fix.

[joemailey]

You sure about the DNS issue?
As everything else runs fine.

What kind of DNS issue would I be looking at, that is preventing the script working and causing long log in time.

I got the script converted to kixtart and it seems to run fine, althou it takes around 1minute to log in.

Here's the code:

;Time in seconds to sleep between request
$SLEEP_PERIOD = 30
$URL_PREFIX = "http"

$ServerName = "192.168.10.49"

;? "ServerName is:"+$ServerName

$AJAX = CreateObject("MSXML2.ServerXMLHTTP")
$wshShell = CreateObject("WScript.Shell")
$strUser = $wshShell.ExpandEnvironmentStrings("%USERNAME%")
$strDomain = $wshShell.ExpandEnvironmentStrings("%USERDOMAIN%")
$strHostname = $wshShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
$command = $URL_PREFIX+"://"+$ServerName+"/adpb/registration?username="+$strUser+"&domain="+$strDomain+"&hostname="+$strHostname+"&action=login"
;? $command
$AJAX.Open("GET", $command)
$AJAX.Send("")
Sleep $SLEEP_PERIOD
$AJAX.Abort 
$AJAX = ""

[sky-knight]

I've never used Kixtart.. that could be the entire issue. The scripting environment has to support background scripts that run indefinitely or the UT logon script is worthless. If you have a working AD I suggest you use the default VB script and push it out with AD with the built in tools.

Incidentally I see no loop in your script, so unless my debugging has failed me that script won't work anyway.

[joemailey]

Sky-Knight:

I pushed it out as a login script. exactly how it says to do it in the wiki.

wiki.untangle.com/index.php/Active_Directory#Supported_Active_Directory_Configurations

But it caused a 20-30min login time.

Any idea of what is wrong? or how I can get around this?

[mrunkel]

If you have a 20 to 30 minute login time, something is very wrong.

By default, windows will kill any login script after 10 minutes of processing time.

It sounds like you've heavily modified your AD setup.

Try this script instead: (replace 10.0.0.1 with the internal IP of your untangle unit)

'Handle or Ignore all errors
On Error Resume Next

'Setup logfile
Set objFSO = CreateObject("scripting.filesystemobject")
Set logStream = objFSO.createtextfile("c:\vblog.txt", True)

'Time in milliseconds to sleep between request
SLEEP_PERIOD = 300000

URL_PREFIX = "http"

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

LogStream.writeline "ServerName is: " & ServerName
LogStream.writeline "Entering the loop..."

Do While True
  Set AJAX = CreateObject("MSXML2.ServerXMLHTTP")
  Set wshShell = CreateObject("WScript.Shell")
  strUser = wshShell.ExpandEnvironmentStrings("%USERNAME%")
  strDomain = wshShell.ExpandEnvironmentStrings("%USERDOMAIN%")
  strHostname = wshShell.ExpandEnvironmentStrings("%COMPUTERNAME%")
  command = URL_PREFIX+"://"+ServerName+"/adpb/registration?username="+strUser+"&domain="+strDomain+"&hostname="+strHostname+"&action=login"
  LogStream.writeline command
  AJAX.Open "GET", command
  AJAX.Send ""
  WScript.sleep(SLEEP_PERIOD)
  AJAX.Abort 
  Set AJAX = nothing
  LogStream.writeline "Here we go again!"
Loop

and look at the file c:\vblog.txt on the computer during the login process. (do it from another machine by browsing to \\[testmachinename]\c$