SSO Client Issues

Hi Josh,

Correct me if I am wrong but you seem to be indicating you are trying to install the STAS (SSO Client) on all PC's, this is not how the SSO works you only install it on the AD Servers them selves.

If you are trying to install an authentication client on the individual PC's you should be using is the "Authentication Client" which can be downloaded from the User Portal on the appliance.

https://community.sophos.com/kb/en-US/123015

The client is available for Windows, Mac OSX, Linux, iOS and Android.

Another option which might assist is implementing the WiFi with WPA2/Enterprise, this would allow you to use the RADIUS SSO to capture authentication events from the WiFi environment.

Hi Leon

I think things have become confused here.

There are two types of SSO which i believe historically have come from the Cyberoam side

1. Clientless SSO or CTA, which uses the STAS software on the server and does not require any software on the client PC's. STAS watches the security log on the server and when it sees a logon event, it ties the username to the workstations IP address and sends this to the XG.
2. Client-based SSO which uses an agent that runs on the Client PCs. You set it up in a login script and it runs at logon to authenticate the client. As per this guide.

I am having issues with SSO (1 above). Because some of the client PC's have both WLAN and LAN connected,  the username/ip address matching only works on the interface over which the initial logon happened. If the client device then decides to use the other connection, the XG has no IP Address to username mapping for that IP.

Anyway to get around this, I thought the Client based SSO (2 above) might be worth a shot, however this is where I am having the issue mentioned in the original post.

Hi Josh,

Apologies, I follow you now.

Basically the SSO Client you are running is executed by the logon script when the user authenticates on the PC, the challenge you are seeing is that it is not executed on when the user changes networks (for example moving from the fixed network to the wireless network) which is effectively the same challenge you are having with STAS.

Both STAS and the SSO Agent track logon events, just changing network does not generate a logon event. I do wonder if you might be able to execute the logon script on network change, if you can it would be a scripting feature.

You can potentially address users moving to the WiFi Network if you implemented RADIUS SSO, this way the WiFi authenticates the user via WPA2/Enterprise and we will get passed the authentication events (log on and log off).

Without RADIUS SSO you would have to rely on the STAS Collector polling the device via WMI which would require various firewall rules and policies to work (including blocking unauthenticated traffic, which will get the appliance to request the user info from the collector and you would also need to set the collector up to monitor that network)

have you already

- setup the WiFi network as a monitored network in the STAS Configuration

- enabled WMI requests from the Collector to the devices in the WiFi Network

- enabled Windows machines to accept the WMI requests from the collector while in both the wired network and the wireless network

if you test the WMI lookup from STAS for a device in the wireless network does it work?

Hi Leon

OK so the SSO local client is no good then, thats unfortunate.

Could you explain how the WMI stuff works? I assumed STAS just watched the security logs on the server?

In regards to the RADIUS Wifi Stuff, it was beyond the scope of what I have been asked to do in regards to the network here (i have just been contracted in to replace their old TMG box with Sophos XG). I dont want to start messing about with other bits.

I Guess this also explains the many failed DCOM errors in the system log on the server? Is this STAS trying to communicate with clients?

I Guess this also explains the many failed DCOM errors in the system log on the server? Is this STAS trying to communicate with clients?

Hi Josh,

Yes, the DCOM errors are probably the STAS Collector trying to Poll the Client PCs. If you check the following article under "Step 2: Configure STAS in ADS" you will see some notes around firewall rules on the client PC's. This will need to be setup on the PC's but also at the firewall allowing traffic between the AD Server and the Client PC.

www.sophos.com/.../123156.aspx

Hi Leon

So does the WMI polling do anything other than just checking to see if the client has logged off?

It also checks who is logged in, so it can pickup user changes and if the user is unknown by the STAS collector/appliance it will check who the user is.

Hi Leon

OK thats interesting, however I dont think thats too useful for me at this point.

I have found a way to run a task based on a network change. This is good. However, this brings me on to my next issue, what should i actually get this task to do? I am assuming I would want it to run the authentication client (local client) again?

The other issue is that I still haven't made the local agent work yet, (see my original post).

Thanks.

We have SSO local clients working properly. The IP of the UTM/XG has to be the default gateway in the PC or you must add a route in the PC (or intermediate L3 switch) for the IP 1.2.3.4 pointing to the UTM/XG. The client uses the fake destination IP 1.2.3.4 to talk to the UTM/XG. I hope this helps.

Hi Jose

It was my understanding that the 1.2.3.4 IP only related to the Astaro based authentication client, not the Cyberoam one?

Hi Josh,

Not sure about it but I know the SSO client as well as the Wifi AP, both use that IP 1.2.3.4 to talk to the UTM/XG. Is the XG the default GW for each PC? If not, just add a route to 1.2.3.4/32 pointing to the XG Lan IP address.

Hi Jose

There are two clients you can use for the SSO, one is the one based on the Astaro System, the other is the one based on the Cyberoam system:

I am trying to use the Cyberoam one, the Cyberoam one allows you to specify the Address of your Firewall using a config file rather than messing around with silly fake IP addresses (what company with more than 50 workstations doesnt use a layer 3 network??)

The Cyberoam one also (according to what I can work out needs no intervention from the end user to Authenticate, it runs at login automatically. Correct me if I am wrong but the Astaro based client does run at logon, but pops up a login box? If that is still the case its useless for me.

I will use whatever client best suits my need as long as I can make it work!

Many Thanks

Josh

We have used Lightspeed system webfilter fairly regularly (maybe i should have used on for this install??) and they seem do the agent thing in a much more sensible way, here's the description.

You customise the installer MSI with the details of your web filter (using their own simple to use tool) and then just do a simple group policy install and thats it, you never see it again, it just runs in the background. It doesnt care how many IP interfaces the client has got, if the client is logged into more than one machine,it just works.

Regards

Josh

Hi Josh,

Just to clarify, the XG Firewall does not limit the number of IP Addresses a user is associated to and even supports session based users identification in Terminal Server environments using the SATC client.

Your chosen authentication methods here are based on login events against active directory, if users move from one network or ip address to another without generating a login event then the change is not tracked. The STAS does support identity checking for unknown ip addresses using WMI which does require AD permissions and appropriate firewall rules through out the network. Otherwise you will get DCOM errors as the Collector is unable to check the user ID for PCs. (Which is what you are seeing)

In most networks I get involved with the STAS with the WMI polling is very reliable for corporate machines, the idea is that you do not actually need to install or run something on the client.

As mentioned earlier in the chain there is another authentication mechanism in the form of a General Authentication agent, this behaves a lot more like what you describe in that is caches user credentials and update the UTM when it connects to it, this does not actually require an ad login event, the username and password combination though can be processed against the active directory.