Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 30 replies
  • Subscribers 8 subscribers
  • Views 11720 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Safeguard

Dan Petford

Hi,

 

I have a number of Desktop PC's and Laptops that are at remote locations that don't require to be on our Domain as they are running Citrix.

 

We have been told to get them to work with Sophos Safeguard, we will need to import the certificate in the 'Personal' section of 'Certificates'.

 

The above has been tried with no success, can anyone help or suggest anything I am missing?

 

Kind regards, Dan Petford



This thread was automatically locked due to age.
Parents
  • 0

    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! 

  • 0 in reply to MichaelMcLannahan

    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.

  • 0 in reply to Dan Petford

    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?

  • 0 in reply to MichaelMcLannahan

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

  • 0 in reply to Dan Petford

    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.

  • 0 in reply to MichaelMcLannahan

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

  • 0 in reply to Dan Petford

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

  • 0 in reply to Dan Petford

    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 

  • 0 in reply to Dan Petford

    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.

  • 0 in reply to MichaelMcLannahan

    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?

  • 0 in reply to Dan Petford

    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?

Reply
  • 0 in reply to Dan Petford

    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?

Children
Unfiltered HTML