I have a few users lately where Safeguard is saying that their username and password is incorrect. However when I try their password I get the same thing. I can get them logged back and sync'd the safeguard server and they can login back in, but every now and again it locks them out again. Active Directory accounts are not locked.
Some of the trouble shooting I have done is:
1: Checked the last key received, last certificate received and last server contacts are all the same
2: Checked the users status which should sgn user (owner)
3: Removed and re-added the certificate and sycn'd with the safeguard server. The key, cert and server contact all match up fine, user is the owner.
4: Removed the cert from the management console and got the user to add their password when they are prompted. This does not work either.
I'm suspecting that the newer windows version are having a problems. Some of the users are on 2004
The version of safeguard that is being used is 8.0.
Any assistance would be great.
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?
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
Snr. New Product Introduction Engineer | CISSP | Sophos Technical SupportSupport Videos | Product Documentation | @SophosSupport | Sign up for SMS AlertsIf a post solves your question use the 'Verify Answer' link.
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