Smoothwall - Kerberos Login Script + Fast User Switching

[Steve21]

Morning Guys,

 

So I'm curious to know what authentication methods people are using for Smoothwall when they have Fast User Switching enabled.

 

We currently were setup and have continued using the Kerberos login script but found you can easily spoof other accounts who are switched over, and get their internet access (e.g. Admin/Teacher as Student). Also logging all internet access as that cloned user.

 

We've been recommended to disable fast user switching as apparently it doesn't work with the script but obviously that isn't a great option seeing that's how the school operates and always has done, and any other authentication method seems to require letting all programs (non-browser) bypass authentication, so if something like Python was used to access the internet or DDOS something it wouldn't be traceable.

 

The kerberos login that works with Terminal Services etc doesn't work with background programs until the browser fires off I've been told so I'm not sure how that'd work with any background programs unless you're keeping a browser window open all the time.

 

Wondering what others who use Fast User Switching currently use, and how they deal with background programs that require access? (Not sure if I'm missing an obvious one or not)

 

Thanks,

Steve

[MicrodigitUK]

I'm interested by what this Kerberos script is?

 

We don't have fast user switching enabled on our domain.

 

Originally we used NTLM site for Domain PCs but this doesn't work well with Office 2013+ well. So we tried Kerberos but this the broke Java apps that don't support Kerberos. So switched back to NTLM and complained to smoothwall.

 

Last summer they released the Negotiate authentication. Basically a mix of Kerberos and NTLM. That is what we use now on domain PCs. All working well.

 

WiFi for BYOD is using 802.1x Radius authentication. That works well people's devices and tracking them on smoothwall.

 

Apple Macs are using Kerberos authentication on a different port just because PCs where using Just NTLM until recently on our main proxy port.

 

Shared iPads all use SSL page authentication with a 1hour timeout.

 

So basically we are using almost all of the authentication methods on the smoothwall apart from Ident authentication. ident is the one with the little client service that publishes the current logged on user to the proxy, can easily be spoofed in ident protocol so never used it. But know other local schools that use it with other non smoothwall proxy setups.

[tom_newton]

The kerberos script is like ident, but unspoofable, but does need to be on a domain (or otherwise trusted) machine. It causes the smoothwall to link an IP and username for a short period (5 mins). Unfortunately the script continues to run on the "switched out" user. Sure it could be solved if someone looked hard enough.

[MouseAT]

I was just looking into the possibility of implementing scripted Kerberos authentication myself, and hadn't really considered the issues raised by fast user switching, so thanks for the heads up on this being a potential issue. I'm going to have a play around over the next few days and see if I can come up with a solution.

 

I've already got the outline of a plan in my head, which will involve (A) modifying the existing script so that it checks that the user session under which it's running is the active one before it tries to resubmit user credentials, and (B) using group policy to run a per-user scheduled task on machine unlock so that a script can submit new credentials as soon as someone switches back to an active session. I've not had the chance to test any of this stuff in practice or work out any possible kinks arising from this, but I think the general idea is probably sound.

 

If I manage to come up with a working solution some time next week then I'll try to come back and post it here.

[Steve21]

Nor had we MouseAT, never had it mentioned as being a problem until during testing we found students with teacher access etc.

 

We're currently working with a Smoothwall Engineer about re-designing that script to work sort of how you mentioned too. However you also need to stop the scripts running on lock etc, else you end up with multiple running again.

 

Need to have a play with the test script we got so far.

 

Thanks,

Steve

[MouseAT]

Yeah, my proposed idea would still result in multiple scripts running in the background as all the inactive users, but because the script would check if it was running in the context of an active session before trying to re-autheticate, it wouldn't be submitting credentials for the inactive user accounts, although it would still be using some CPU and RAM in the background. It'd be clunky, but hopefully it'd work.

[MouseAT]

OK, I've been playing around a bit with this on Windows 8.1, and I think I have a rough proof-of-concept framework for getting this to work.

 

The first script (that runs at log-on) is more or less unchanged. Just set the path to the second script and be done with it.

 

LoginScriptLauncher.vbs

Option Explicit

'Declare and create shell object
Dim objShell
Set objShell = WScript.CreateObject("WScript.Shell")

'Run BackgroundProcess.vbs in a separate process (so that the script doesn't get killed by a login
'script time-out threshold).
objShell.Run "\\PATH_TO_SCRIPT\BackgroundProcess.vbs", 0, False

 

The second script is the one containing the main code loop. Again, there's a path to a payload script that needs setting.

 

For the moment, I'm using a 5 second sleep time at the end of the script for testing. This will need increasing to a more reasonable value on a production script.

 

Here's the basic logic: When the script first runs, the script obtains the username of the user running the script from the Wscript.Network object. Each time the script loops, it asks WMI for the username of the active console session, and compares it to the username from Wscript.Network. If the usernames match, then the script knows that the user is active, and that it should execute a payload from a third script. If the usernames do not match then this script is clearly running under a user account that is not the active console session, so we don't want to do anything right now.

 

Please note: This works fine for a client system that can't have more than one active console user. It'll produce some "interesting" results if run on a system with multiple active sessions such as a remote desktop server. How "interesting"? I don't know. I haven't tried it.

 

BackgroundProcess.vbs

Option Explicit
On Error Resume Next

'Declare Objects
Dim objShell
Dim objNetwork
Dim objWMIService
Dim strScriptUser
Dim strCurrentConsoleUser
Dim colItems
Dim objItem

'Create shell, network and local computer WMI objects
Set objShell = WScript.CreateObject("WScript.Shell")
Set objNetwork = CreateObject("Wscript.Network")
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")

'Compile the user name of the user running this script, in the format DOMAIN\username
strScriptUser = objNetwork.UserDomain & "\" & objNetwork.UserName 

'Begin loop
Do While (True)

'Clear strCurrentConsoleUser, just in case the next command fails. I'd rather have 
'authentication fail closed, rather than fail open.
strCurrentConsoleUser = ""

'Obtain active console user from WMI. The active user is returned in the format DOMAIN\username
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem",,48)
For Each objItem in colItems 
	strCurrentConsoleUser = objItem.UserName
Next

'Perform case insensitive comparison of strScriptUser and strCurrentConsoleUser. Returns 0 on
'match. Execute payload only if the user account running this script is the active console
'session.
If StrComp(strCurrentConsoleUser, strScriptUser, vbTextCompare) = 0 Then
	objShell.Run "\\PATH_TO_SCRIPT\CommitUserData.vbs", 0, True
End If

'Sleep for a predetermined period before attempting to execute the payload again
WScript.Sleep 5000
Loop

 

Finally, my test payload script. For now, it appends the current date, time and both versions of the user name to a text file called VBS_Log.txt in the current user profile. This is so that I can check all of the log time stamps and ensure I'm getting the intended behaviour.

 

In the production version of the script, this should be the script that connects to the Smoothwall and sends Kerberos credentials. I've not got far enough to test that yet. I don't have Kerberos enabled on my Smoothwall yet.

 

CommitUserData.vbs

Option Explicit
On Error Resume Next

'Declare Objects
Dim objNetwork
Dim objFileSystem
Dim objTextFile
Dim objWMIService
Dim strCurrentConsoleUser
Dim objItem
Dim colItems

'Create network, file system and WMI objects
Set objNetwork = CreateObject("Wscript.Network")
Set objFileSystem = CreateObject("Scripting.FileSystemObject")
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")

'Obtain active console user from WMI. The active user is returned in the format DOMAIN\username
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem",,48)
For Each objItem in colItems 
strCurrentConsoleUser = objItem.UserName
Next

'Open a text file in the local user profile. Flag value of 8 means "append"
Set objTextFile = objFileSystem.OpenTextFile("C:\Users\" & objNetwork.UserName & "\VBS_Log.txt", 8, True)

'Append the date, time and user name of the user account under which this script is running
objTextFile.WriteLine(Date & " " & Time & " " & objNetwork.UserDomain & "\" & objNetwork.UserName & " " & strCurrentConsoleUser)

 

There's one last thing that needs to be taken care of. When we fast user switch back to an idle session, we need to ensure that CommitUserData.vbs runs immediately to update the Smoothwall authentication data. I reckon this can be done through a scheduled task in Group Policy. The trigger to use should be "Connection to user session", "from local computer". Also, the settings need to be configured so that the task can run when the computer is on battery, as the default is only to run when on AC power.

 

I'm still playing around with this to ensure it works as intended, but my initial trials look good, and I reckon the logic is sound. If anyone else wants to take a look, play around and report back, feel free to give it a go. Any feedback would be appreciated.

[simoanorak]

We have proposed a script to terminate the process when the screen locks. A scheduled task can be set up to kill the screen when the screen locks. And an accompanying script when the screen unlocks. The unlock is just the background login script already provided by us and the kill script is

 

set objwmiservice = getobject("winmgmts:\\.\root\cimv2")

strprocessname = wscript.arguments.item(0)

strquery = "select * from win32_process where name='" & strprocessname & "'"

set colitems = objwmiservice.execquery(strquery,,48)

for each objitem in colitems

objitem.terminate

next

 

where the script is wscript.exe

 

I haven't tested this in a windows server environment yet to check the ownership of the script and it's affect on the user logged into the Smoothwall. I hope to test later this week. The script does stop multiple instances of the login script running.

If anyone is able to test sooner then I would be interested in feedback.

[Steve21]

We have proposed a script to terminate the process when the screen locks. A scheduled task can be set up to kill the screen when the screen locks. And an accompanying script when the screen unlocks. The unlock is just the background login script already provided by us and the kill script is

 

set objwmiservice = getobject("winmgmts:\\.\root\cimv2")

strprocessname = wscript.arguments.item(0)

strquery = "select * from win32_process where name='" & strprocessname & "'"

set colitems = objwmiservice.execquery(strquery,,48)

for each objitem in colitems

objitem.terminate

next

 

where the script is wscript.exe

 

I haven't tested this in a windows server environment yet to check the ownership of the script and it's affect on the user logged into the Smoothwall. I hope to test later this week. The script does stop multiple instances of the login script running.

If anyone is able to test sooner then I would be interested in feedback.

 

Got it all setup on my test bed ready to test when I get a minute, just been crazy few days Will let you know how it goes.

 

Only one thing I did notice from the script from a quick test before, but I guess there's no way around that is it'll kill all running scripts, not just the Smoothie. But guess that might have to be a compromise in the mean time

 

Steve

[MouseAT]

Just watch yourself on the scheduled tasks when using asynchronous policy processing to create them. I've been playing with a scheduled task that should run for a user, using the "connection to user session" trigger. The first time I logged on as a user, switched away from the session and switched back, it didn't appear to trigger the task. Only after I logged off and back on did the scheduled task start triggering properly. Just something to watch out for.

[tom_newton]

Some quality suggestions on here - I tellst thee it could be done if you looked hard enough Hope Smoothwall take this on and improve the shipped version.

[plexer]

Logon scripts for user authentication against a proxy just sounds yuck

 

Ben

[ITGuyWestMidlands]

Surely a windows service with hooks into the sens api would be more fitting. Still a little rough but gotta be better than scripts and scheduled tasks?

[dan_at_smoothwall]

It's not that bad - for the standard scripts that we give out all you have to do is push them out via group policy and set one of them to run as a logon script in group policy.

@tom_newton I know! It's great Harry concurs with you.

@ITGuyWestMidlands definitely! That's what we'd like to do. It's just a matter of finding the time. While the use of scripts may not be the absolute tidies way to do it, it's working well - we have a lot of customers using it, and very few having issues/complaining. As a result, there's things of a much higher priority to be done. If I could clone all our developers for free...

[Steve21]

it's working well - we have a lot of customers using it, and very few having issues/complaining. As a result, there's things of a much higher priority to be done. If I could clone all our developers for free...

 

I'd love to know how they use it with Fast User Switching on though, I can't believe (as it seems to be said often) that no-one else is using fast user switching at any Smoothie install.

 

Unless they're all using it with the permission issue though?

 

Had no problems with the script and using login etc until we found this, and seems it's known not to work with user switching and never mentioned when we were told to use it.

 

But either way, hopefully the "new" script we're doing will work

 

Steve

[dan_at_smoothwall]

@Steve21 - you're right. I should have added that we tend to advise using alternative auth methods when customers are using fast user switching.

 

I'd love to deal with it... but alas. No cloning!

[Steve21]

@Steve21 - you're right. I should have added that we tend to advise using alternative auth methods when customers are using fast user switching.

 

I'd love to deal with it... but alas. No cloning!

 

Beware of the clones!

 

 

But aye Hopefully this will get best of both worlds if the changed script works

 

 

Steve

[Steve21]

Found some problems with the VBS script originally discussed with Smoothwall as it's killing itself randomly depending what order it kills Wscript.

 

Re-designed it to run constantly without needing ot be killed but it only fires off if it's the active user.

 

Seems to work fine through testing so far, but obviously test yourselves

 

On Error Resume Next

Dim shell
Set shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "Smoothwall Test - Logon START"

Dim winhttp
Set winhttp = CreateObject("WinHttp.WinHttpRequest.5.1")

strComputer = "."   
Set objWMIService = GetObject("winmgmts:" _ 
             & "{impersonationLevel=impersonate}!\\" _ 
             & strComputer & "\root\cimv2") 

Set wshNetwork = CreateObject( "WScript.Network" )

Do While True
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem",,48)
For Each objItem in colItems 
	strCurrentConsoleUser = objItem.UserName
	strCurrentDomainUser = "MYDOMAIN\" & wshNetwork.UserName

	shell.LogEvent 4, "Testing " & strCurrentConsoleUser & " and " & strCurrentDomainUser 

	If strCurrentConsoleUser = strCurrentDomainUser  Then
		shell.LogEvent 4, "Matched: " & strCurrentConsoleUser & " and " & strCurrentDomainUser 
   			winhttp.Open "GET", "http://smoothwall.MYDOMAIN.sch.uk/kerberoslogin"
		winhttp.SetAutoLogonPolicy(0)
		winhttp.Send
	else 
		shell.LogEvent 4, "No match: " & strCurrentConsoleUser & " and " & strCurrentDomainUser 
	end if
Next

WScript.Sleep 120000
shell.LogEvent 4, "Smoothwall Test - Logon PING"
Loop
shell.LogEvent 4, "Smoothwall Test - Logon END"

 

Will do a few more days testing before rolling it out to some users to test live

 

Steve

[simoanorak]

Found some problems with the VBS script originally discussed with Smoothwall as it's killing itself randomly depending what order it kills Wscript.

 

Re-designed it to run constantly without needing ot be killed but it only fires off if it's the active user.

 

Seems to work fine through testing so far, but obviously test yourselves

 

On Error Resume Next

Dim shell
Set shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "Smoothwall Test - Logon START"

Dim winhttp
Set winhttp = CreateObject("WinHttp.WinHttpRequest.5.1")

strComputer = "."   
Set objWMIService = GetObject("winmgmts:" _ 
             & "{impersonationLevel=impersonate}!\\" _ 
             & strComputer & "\root\cimv2") 

Set wshNetwork = CreateObject( "WScript.Network" )

Do While True
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem",,48)
   For Each objItem in colItems 
       strCurrentConsoleUser = objItem.UserName
       strCurrentDomainUser = "MYDOMAIN\" & wshNetwork.UserName

       shell.LogEvent 4, "Testing " & strCurrentConsoleUser & " and " & strCurrentDomainUser 

       If strCurrentConsoleUser = strCurrentDomainUser  Then
           shell.LogEvent 4, "Matched: " & strCurrentConsoleUser & " and " & strCurrentDomainUser 
               winhttp.Open "GET", "http://smoothwall.MYDOMAIN.sch.uk/kerberoslogin"
           winhttp.SetAutoLogonPolicy(0)
           winhttp.Send
       else 
           shell.LogEvent 4, "No match: " & strCurrentConsoleUser & " and " & strCurrentDomainUser 
       end if
   Next

WScript.Sleep 120000
shell.LogEvent 4, "Smoothwall Test - Logon PING"
Loop
shell.LogEvent 4, "Smoothwall Test - Logon END"

 

Will do a few more days testing before rolling it out to some users to test live

 

Steve

 

Great Work.

We'll do some testing also. Get in touch if you need anything.

Thanks!

[MouseAT]

I was playing around yesterday with a proxy port set to NTLM (via redirect), and found that the fast user switching didn't seem to track users accurately. I'm playing around at the moment using core authentication, and things look like they're better, although I've not had chance to really hammer on it. I'm wondering whether an application running under an inactive user (eg. a web browser) was submitting its own credentials via. NTLM and disrupting the user tracking. If so, we may need to think carefully before allowing any sort of fallback authentication method if we're using fast user switching.

 

Just food for thought. I'll try to provide some more in-depth feedback after I've had chance to play with this a bit more.