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

When you say the account is locked out, can you confirm that this is the case for the locally created account, i.e. the sophossau... one?

Hello Jak,

How to confirm, if this is the case for default / system created acct ? Also see the log of one of the PC for example.

Regards

Faisal

Hello Faisal,

How to confirm
Start → Computer, right-click → Manage, Local Users and Groups → Users → click the SophosSAU... user.

Christian

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

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

++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

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

Hi QC and Jak,

Why there's an error "Differs from policy" with some of the machines ? Any idea.

Regards.

Faisal

Hello Jak,

Is there any procedure to set IIS as https rather than http for security ?

Thanks for your best support.

Regards

Faisal

I don't believe that version of SAU supports HTTPS at least from a non Sophos update location.  I know that the Sophos Central AutoUpdate client can pull files using HTTPS.

That said, the files being downloaded over that channel are just Sophos files.  Unless you put your own custom files in the CID (configcid.exe [https://community.sophos.com/kb/en-us/13112] would need to be used), then you're only downloading.  SUM on the server is pulling the same set of files using HTTP also.

There is no chance of tampering with the files as they all have content derived names and signatures are used.

As for differs from policy, which component differs?  This article is a good starting point: https://community.sophos.com/kb/en-us/113069

Regards,

Jak

Hi Jak / QC,

Having an issue with some machines as below screen shoot. Also the way http has started generating the traffic on network as we are using QRadar for log monitoring there we can see that Sophos is using "user" account and Authentication failures messages being generated :( . Any tip to resolve this issue ?

Regards

Faisal

Given the screenshot, there are potentially a number of issues.

The "Not since x" updating messages, these could be fine, without seeing the connected state of the endpoint or last message time it's hard to say if these are OK.

There are a number of errors of course but I can't see the details.  You might have to focus on one error/computer initially.

As for the QRadar log monitoring, which user account are you seeing issue with?  The local sophossau account or the account defined in the updating policy?