Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 6593 views
  • Users 0 members are here
Options
Suggested
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

AutoUpdate seems to use local SophosSAU<hostname> for authenticate to SophosUpdate share

JSCR

We are running SEC 5.2.2 and two Message Relay Servers with  SophosAV 10.6. All SEC clients are Windows 2012R2 Servers, including SEC and MRS.

One MRS is set up in a different Domain than the SEC Server.

On this MRS enviroment/domain we get those 1326 and 86 windows errors, which say, that SophosUpdate share can not be reached due to authentication failure.

Share permissions on MRS are checkt and OK.

Update user is a domain user - credentials are checked with net use against the update share and are OK

Update Policy is checked and OK. Reentered User und Password into Update Policy just, just in case..

On  the Eventlog\security\ on the MRS I can see, that the problem-clients are trying to connect to the SophosUpdate share with their local SophosSAU<Hostname> user account. Event: Audit Failed

In the ALUpdate-Log on the clients is the correct SophosUpdate user shown.

The only machines in this domain which get updates are the two domain controlers, which seem to use their domain\SophosSAU<hostname> user accounts, and the MRS itself, which seem to use its local SophosSAU<hostname> user with success.

Why is Sophos AutoUpdate using this SophosSAU<hostname> user instead of the Sophos Update user from the policy? Where can this be fixed? Anybody seen this before?

regards

Joerg



This thread was automatically locked due to age.
Parents
  • 0

    Hello Joerg,

    Why
    AutoUpdate runs as Local System. When it tries to access the update share it uses the credentials from the updating policy. You can check this using Wireshark capturing traffic on port 445. If the credentials are rejected AutoUpdate retries with the SophosSAU user. Apparently it makes five retries, don't ask me why. That it retries at all is more or less understandable as the share could be accessible without credentials. IIRC the impersonation account is needed to avoid a NULL session on older Windows versions.
    Anyway, the update user is presented first and only subsequent  NEGOTIATE requests use the impersonation account. You don't see any failed logons for the update user? Is the user in the policy specified with the domain qualifier (just asking because it works for the DCs)?

    Christian     

  • 0 in reply to QC

    Hello Christian,

    thank you for your reply.

    I know, that AutoUpdate is running on Local System account -> using SophosSAU for network access -> using SophosUpdate User for share access.

    If I got you right, AutoUpdate ONLY tries to authenticate against the share with SophosSAU AFTER the credentials of SophosUpdate User from the Update Policy are rejected, right?

    No, I don't see any failed logons for the SophosUpdate user

    And yes, the user in the Update Policy is specified with doamin qualifier. Correct Path, correct abonement. We checked the iconn.cfg on the clients too. The only thing, did not check is if the password hash in the iconn.cfg is correctly obfuscated.

    For the DC's, I only see the successful logon with SophosSAU.

    Joerg

Reply
  • 0 in reply to QC

    Hello Christian,

    thank you for your reply.

    I know, that AutoUpdate is running on Local System account -> using SophosSAU for network access -> using SophosUpdate User for share access.

    If I got you right, AutoUpdate ONLY tries to authenticate against the share with SophosSAU AFTER the credentials of SophosUpdate User from the Update Policy are rejected, right?

    No, I don't see any failed logons for the SophosUpdate user

    And yes, the user in the Update Policy is specified with doamin qualifier. Correct Path, correct abonement. We checked the iconn.cfg on the clients too. The only thing, did not check is if the password hash in the iconn.cfg is correctly obfuscated.

    For the DC's, I only see the successful logon with SophosSAU.

    Joerg

Children
  • 0 in reply to JSCR

    Hello Joerg,

    I only see the successful logon with SophosSAU
    hm ... works because for the DCs it's a domain user. A Wireshark trace would tell if the update user is not tried or if the logon fails (the questions why and why there's no Security log entry remain).

    Christian

  • 0 in reply to QC

    Hello Christian,

    your first reply already gave me some hints I will follow tomorrow with the coleges.

    This Domain I'm talking about is one of our special protected onces, where all traffic is IPSec tunneled. So we can't see anything with Wireshark or Netmon.

    I will try to check with sysinternals Process Explorer and will come back with our results.

    Joerg

Unfiltered HTML