Safegaurd keeps saying users username and password is incorrect - but not

Hi - Not what you want to hear, but you WILL need to update these clients to a newer version. This link lists all the versions nicely

SafeGuard Enterprise: Supported clients on Windows 10 versions (sophos.com)

I wouldn't expect this to cause password issues, at least this would be the first I've heard of it - but having a known compatible version/client is the first starting point I'm afraid! 

Thought that would be the case. It doesn't happen all the while though that is the weird thing. Are there any other suggestion?

In your step4 I personally delete the cert/key of the server for the user, and then get them to log off and back on. Once "Initial user synchronisation" is seen - They should be good to go. Are you saying that doesn't happen, or it doesn't prompt? Can you also confirm that the users ARE logging in with the Sophos "cog"/Credential provider?

I can retry that step, but when I 1st did it, it never sync'd with the server until I added the users cert back. They are using the cog login. I have got the laptop back and currently testing it with the user login. I can't seem to replicate the issue.

Are these local users or domain bound Robert?

Are these local users or domain bound Robert?

Domain accounts I thought that win 10 cached the credentials which allow users to login?

Yes if you have it configured that way - that's the default. If I ever get a user cert/key mismatch, they should still be able to log in. However they will see an exclamation mark over the SSSG icon and often a secondary prompt to log in again. I then remove the key on the server - get them to log in again (sometimes twice - I think some hardware is too quick for Sophos!) and then the device syncs and recreates the cert/key again with the correct details. 

Interesting it do see this in the management centre , Logon SGNCredProv failed. Logon method: password. Reason: Authentication failed, I think this is safeguard trying to contact the server. Are there any logs on the machine that could give a reason for it? I've managed login in every time to the laptop that I am testing. I've disconnected it from the corporate network and put it on an external facing access point to see if I can replicate it. I will need to connect to the VPN as well at some point. I personally think it is going to be very tricky pin point what the cause is.

you should nav to the sgn server URL from the client and see if it displays properly without a cert error

Is there a way to decrypt the hard drive? Tried removing it but does not decrypt. Let me know ASAP

Yes, but this is dependant on policy. IF you have decryption/uninstall available in the active policy then it will. Or create a policy that allows it, install this and then decrypt or uninstall if needed. If you just try to decrypt the SSG will overpower this and just re-encrypt. This is for security - it's not a fault.

From the policies I can see the decryption isn't on any group policy. how would we decrypt the hard drive once applied? When building machines I would use powershell and use command manage-bde -on c: This encrypts the drive. Would the reverse need to be done? Also I have noticed that out of the box machine encrypt straight away. Is worth decrypting before adding safeguard?

Also where can I see what policy is applied from the client end?

Yes, select the client and use the RSOP tab to calculate what policies are applied to the client and in what order. Putting in a username will give you the resulting policies for that user. It can be left blank. Click Calculate. The summary of all the settings applied to that client will then be shown. The two settings you want to be looking for are " Uninstallation allowed" - under Machine Settings and "Media encryption mode" in Device Protection. That said there are other ways/settings to allow decryption but I'd start there!  Personally when I decrypt a client/remove SSG I have a configuration MSI to run locally that has a default decryption/uninstall available as the default. I have known on many occasions that despite the latest policy being applied - the client will still not apply this change. Installing the policy locally rarely fails to work! 

Ok thanks I will take a look. I have removed SG and decrypted the hard drive, added SG back and re-ecnrypted to see if that solves it. I have also noticed that there may be a bug in the 2004 OS that stops users logging in with username and password