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

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
  • 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.

  • 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?

  • How do the domain clients sync, as they have the same secondary cert.

    It's very strange how a domain client that's not on our LAN or VPN is syncing?

  • Hi Michael,

    Still having issues with the non-domain PC's, however also having the same issue with domain PC's.

    The PC in question is not appearing in the console, if I import I get the attached message.

  • That's a nasty looking error! So are other PC's importing fine and it's just this PC, or none importing?

    It is possible to have clumsy duplicates in the console too - Have you verified this exact host doesn't exist already (or hasn't been renamed and the "old" version of it still exists?

    Are you logged in as MAINMSO when this is seen, or another user? If you haven't tried MAINMSO it may be worth trying that account to rule out perms?

  • Hi Michael,

    Just thought I'd update you on our progress with the 'Workgroup' machines, we have managed to successfully get it sorted, the reason was we had a batch file that we used to install Sophos SafeGuard, if we run the installation files manually it works fine.

    On a side note we do however get the attached screenshot, is there any way of stopping this?

  • Well done, good work! I had assumed that you'd used the standard install, I should have asked you that sorry!

     

    This window will come up if you didn't log in via the "Sophos Cog/Credential provider" OR if you did - it didn't pass through authentication.

     

    I can see this user is called "User". I would recommend against this - use something at least unique for each machine. User1, User2 sort of thing. 

     

    It's worth making sure you've confirmed the users too. As they're not in the directory (as they're bound to an independent workgroup) SSG won't know who they are. 

     

    So confirm each user - This will be easier if they're all not just called "User" as I've said.  On the console - Scroll right down past your directory. Your WorkGroup will be at the bottom.

     

      

    Open the .Unconfirmed Users - right click each user and confirm (Or RClick confirm ALL users). This will then allow them to be known users and should avoid the Window you're seeing (assuming you ARE using the Sophos Cred Provider to log in!

     

  • Hi Michael,

    Managed to get this all working now, however trying sort out the support side of things if users forget their PIN, we have managed to successfully use the SafeGuard Enterprise Helpdesk and access the 'Recovery' for domain users, however how does the 'WORKGROUP' support work as can't seem to get this to work?

    Kind regard, Dan

  • Hi Dan - It "should" be the same procedure. Make sure you've assigned the access on the console to the workgroup. Log on as that staff user with the associated creds and once you've selected the Recovery tab it should allow you to use the drop down to select the "other" domain/workgroup?

     

  • Thanks Michael, how do I assign the access on the Console to the Workgroup so that this shows in the Enterprise Helpdesk?

Reply Children
  • Log onto console (MAINMSO would be handy as it SHOULD have permissions to view everything) and scroll down to your Workgroup (right below the domain and all the jazz)

    1 - Select the Workgroup

    2 - Select Access tab

    3 - Select a security officer (one from the domain)

    4-  Drag them over to the Access window and give them appropriate rights.

     

      

  • Perfect, worked!

    Thanks so much, kind regards, Dan

  • No problem, really pleased you’ve got it all working!

  • Hopefully this is the last question :-)

    I have managed to get the recovery working now via Workgroup, when providing the recovery key, the test machine accepts it and then boots to Windows.

    Once logged in, it asks to enter a new pin, however when trying I get the attached error.

  • Morning Dan - This is an expected error when you only have one key protector set.

    There's a few key protectors to help "secure" the data/encryption on the HDD/SDD.

    Some of these are...

    TPM (Only)

    TPM AND PIN

    Password

    Startup key (a USB memory key to be plugged in (or left in?!) each and every boot. 

    Numeric Password (This is the recovery key in all digits) This is your "emergency key" and the one the Sophos server holds.

     

    What this error is telling you is that it's been asked to delete the only key remaining. You can only have ONE active protector AND the recovery key (the numeric password)

    This PC is telling you that to add another protector it must first delete the other one. However that would leave it with NO key protector as there's not another set!

    Does that make a bit of sense?

     

    What you need to do is check your policy - Make sure you have a TPM policy that can be applied AND the PC can use it. TPM MUST be in an accessible state (this can be cleared from BIOS or using the TPM.MSC tool within Windows (at an elevated prompt)

    You also need to check "manage-bde" (also at an elevated prompt) 

    manage-bde -status

    If is says there's two key protectors set and working then we need to figure out why the TPMANPIN policy isn't setting. You can manually add a key proctector at the manage-bde prompt but this should be being set by Sophos so applying it this way isn't really fixing the issue - at least not globally!

     

    manage-bde -add -protectors -TPMANDPIN c: 

    This will replace the key protector with TPM AND a PIN (it'll then prompt for a PIN)

     

    You're very close now though - don't give up! :)

     

  • Hi Michael,

    Resetting the TPM worked in the TPM.MSC.

    Kind regards, Dan

  • Great news - well done! So your workgroup laptop can happily reboot, be prompted for PIN and you have the recovery key within the console (accessible via the WebHelpDesk too) for the Workgroup machines as well as the domain?