A Windows API call returned error 1909 [0x00000070]

Hello Faisal,

this is strange as the accounts mentioned are apparently the local SophosSAU accounts created by the installer (with User cannot change password and Password never expires set). Does this affect all endpoints and when did this start?

the account in local machines its not locked
As only AutoUpdate uses this account and should "know" the correct password I can't see why the lockout should occur in the first place. The lockout time is set with the Account Security Policy (minimum one minute) so they might get unlocked automatically.
AFAIK AutoUpdate nevertheless tries to make the connection and updates should succeed if there is no other issue. Are the endpoints shown as up to date in the Console? 

Christian

Hello QC,

Regarding the endpoints update, please find attached screen shoot.

Regards

Faisal

Hello QC,

This is what I know but how to check whether its the same account is locking or some other is getting locked. 

The issue is why its getting locked and then itself getting active.

Regards

Faisal

Hello Faisal,

why it's getting locked
that's the puzzling part. AutoUpdate either has the correct password or not. In the latter case it should report the 1909 (or a 1326 - incorrect password) for every update attempt.

It looks like an account lockout policy is in effect with a finite lockout duration that causes the accounts to get unlocked. This does not explain what gets them locked though. By default workstations don't audit failures, if failure auditing is turned on the Security Event Log should show which process is responsible.

Christian 

What is the default time set for account locked out ? Is there any policy in Sophos for this settings?

What's the best practice for signature update time in workstations? Should this be every an hour or twice a day ?

What's the fastest solution to resolve this issue ?

Regards

Faisal

QC will probably provide you with a fuller answer.  I'm currently on holiday and only have a Mac.

One thing that *might* help, and could be a quick fix would be to setup a web cid - https://community.sophos.com/kb/en-us/38238. There is a chance that the local sophossau account is only used for UNC updating.  If the clients were using HTTP the issue could just go away.  Might be worth a quick try. Should only take 10 minutes to try.

If this did "fix" it, it would at least buy you some time for troubleshooting on maybe a single client using UNC.

For what it's worth, the Sophos Central client, which uses Sophos AutoUpdate XG, doesn't even create a local account.  So if you were to switch to Sophos Central this issue would also be removed.

Regards,

Jak

Hello Faisal,

any policy in Sophos
no, account lockout is a Windows setting and as said, I don't see how AutoUpdate could cause this behaviour. Could you show the errors in the updating log from an endpoint (local Sophos GUI → View updating log) starting at the end of a successful update like this:

Christian

++Jak

In this case I suspect all the update traffic will route to internet, I can't use the internet for big number of machines.

Please correct me if I am wrong.

Regards

Faisal

No, you can get the clients to update from your server but rather than using UNC, they can use HTTP.

So if you have say a single management server, this is maintaining a CID/Distribution point.  If you add the IIS role (you could use any web server), you can share the CID/Distribution point out using that.  The KBA details IIS.

The clients can then use http://server rather than \\server\ for example.

Regards,

Jak

QC,

How to know from the console about the machine account? used for update ? i.e.

Regards

Faisal

The local machine account (SophosSAU...) is created by the AutoUpdate installer.  

Note: You can follows this procedure:

https://community.sophos.com/kb/en-us/48910

...if you want to use your own account.  I'm not suggesting this as a fix but knowledge of this maybe useful for troubleshooting as at least you'd have control over the account/password etc..

The local account is used by the update process (alupdate.exe) to be able to "see" the network as the process is running as SYSTEM.  It then goes on to perform the download from the server using the updating account specified in the updating policy.

Maybe QC can confirm; as I'm sure he has at least one client using HTTP updating and I only have a Mac available to me at the moment, that if you enable auditing of account logon events at the client, with HTTP updating, the SophosSAU account is not used.  For a client which is performing UNC updating, I assume you see the auditing event for the sophossau account.  This could prove if it's not used with HTTP vs UNC.

Regards,

Jak

Thanks Jak,

Using the link you provided with "http" has solved my issue. My one last question is about the security. Is it secure to use this way or unsafe ? 

Thanks

Regards

Faisal

Thanks Jak,

Using the link you provided with "http" has solved my issue. My one last question is about the security. Is it secure to use this way or unsafe ? 

Thanks

Regards

Faisal

Any advise for this issue ?

Regards

Faisal

Hello Faisal,

the Download failed errors are usually transient (i.e. a subsequent download/update succeeds)
Could not find a source might be transient as well (happens for example when an endpoint tries to update when the network connection is not yet established)
I have a few endpoints that report the correct update location but updating fails with no update source. Have not yet determined the actual cause, a reinstall might fix this
Finally the Failed to install - you'd have to check the Sophos Anti-Virus logs (Install, Uninstall, MajorActions) in \Windows\Temp\ on the endpoint

Christian