Sophos Safeguard

Hi Dan - Although they're not on the domain, are you treating them like domained machines?

Does your SafeGuard server have a secondary DMZ server, or is the primary server accessible to them (via public/VPN etc..)

They can work with Sophos but they either have to have access to the server, or treated as standalone clients. With the standalone clients you can create a package configuration file to apply to the client that contains the policies, but the key backup location would have to be stored somewhere for the recovery of the device - ideally somewhere centrally and obviously not stuck on the client! 

Yes, we do have a secondary server in dmz (well port forwarded actually, but same end result) – that’s what allows the remote domain-joined PC’s to sync with safeguard. Just to clarify that remote domain computers are fine, just the workgroup ones that won’t connect.

I did find that the local machine required a password, so have set one, and it started to initialise, however it still doesn't connect to the server, and the status is a Guest now.

Ah ok - Thanks Dan. Sounds like you've set it up well. Have you created a matching workgroup name for the remote laptops and are they all in the same workgroup name?

If the workgroup name (you could just use "workgroup" but a bit lazy/confusing!) matches the workgroup name on the clients, they'll populate the auto-registered group. 

You could then apply the same policies from your successful machines to the "auto-registered" workgroup folder. 

Sophos client doesn't like blank passwords on accounts, so always best to set one. 

It's also worth using the client connection tool (assuming you have V7 or better?)  - ON the client, C:\Program Files (x86)\Sophos\SafeGuard Enterprise\Client\SGNCSCC.exe.

Please see the report attached of the connection tool

Please see the report attached of the connection tool

And you have a valid public SSL cert applied to this DMZ/ported server? No chain/intermediary certs needed on the DMZ server?

Your remote domained PC's that DO connect - are they connecting to the same server or the primary? Are they connecting with a VPN or without? If it's a VPN are the DNS routing tables allowing a connection rather than the DMZ server being truly public?

They are connecting to the same server, our remote domain ones are via a VPN and work fine.

Then it could be the DNS routing of the VPN client is what's making the client work on those laptops, and not the availability of the DMZ server?

Can you install the VPN client on the un-domained PC's to test this? If this works (which I now suspect it will) then it's the availability of the DMZ that's in question - not the client.

We have tested a Laptop on the Domain, connected via 4G and SafeGuard still synchronises without our VPN client connected.

I have now tested with a VPN and the synchronisation still fails.

I still suspect DNS/routing here. If the DMZ is publically accessible it should be accessible to all clients - domained or not. 

If you open a browser on the device and type in the address does it resolve the page? https://yourserver.yourpublicdomain.com/SGNSRV/trans.asmx 

Yes it does resolve.

Well it's progress! :)

Can you confirm you have BOTH primary and secondary p7b certs within c:\programdata\Ultimaco\SafeGuard Enterprise\LocalCache\transout\config.

You can view them in Notepad and you should see your DNS resolved name in plain text in there (scroll to the right, it's about halfway in)

Can you also check that this is the correct publically addressable name of the SSL cert too. 

These are the locations of the certs placed there by the configuration tool MSI.

I can confirm both Primary and Secondary certificates are present in the above location.

For some reason the Secondary only shows the internal hostname, not sure if this is correct or not?

No it's not correct and would explain why the client can't resolve the secondary DMZ server (Your primary is the internal server right?)

I would check the configuration MSI again - it's possible to unzip it using 7Zip or similar and view the contents 

The secondary cert must be in the publically resolvable external hostname, as that's how the client will resolve the server address.  It would explain too why the domain bound client would resolve this address/DFS too.

Can you use the configuration tool again to produce a "new" client MSI, extract and read the contents and then check the secondary cert address again?

If it's the internal address still this will need to be corrected. I would suspect that applying the server configuration again to the secondary server should resolve this?