Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 4044 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

Client protection with local Windows Policies Enabled

uiltgilgiluhgjo

Hey

I Configured a Server (Workgroup Enviroment) with sophos Enterprise Console 5 which works on clients with no local windows policies enabled all clients get there updates and sophos works very well.

Now i got another network with the same configuration only now all this clients have Windows security policies enabled.

Now when i try to push sophos to this Client i get the 3051 error which means the Server cannot create the SophosSAU<computername> or the password(policy) account for some reason.

Things i done to solve this problem:\

- Put policies off > Result is that everything works but i want policies enabled so this is not a solution for me.

The fault is that  the clients policy ask for a complex password  like 7 characters and a number for example

which causes Enterprise Console to give the 3051 error

My question is:

- Is there a possibilty to let the server (Enterprise Console) make a  local SophosSAU<computername> account  on the client with a complex password? and how to do that? or a workaround for this?

Greets Ronnie

EDIT:

i found this topic:

http://www.sophos.com/support/knowledgebase/article/48910.html

My question is is this for server side or client side? and anything to configure after?

:22283


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

    You must create the account before protecting the clients. AutoUpdate will use the preconfigured account (and not create one with another suffix - this is normally only used on DCs). As these are local accounts the action must be performed for each client. Adding the required keys (by whatever method) should be pretty straight forward.

    The AutoUpdate service runs as LOCAL SYSTEM and therefore has no access to network resources. In order to download updates it must impersonate an account which does - this is the SophosSAU<COMPUTERNAME>0 user. Acting as this user AutoUpdate then accesses the CID using SophosUpdateManager (or whatever is specified in the policy).

    i guess more people should have expierenced this same problem

    Yes, but I know of no article or doc specifically addressing this (at least I haven't found one). So I wonder what's the official answer from Sophos, whether a defect has been raised or a suggestion accepted.

    Christian

    :22303
Reply
  • 0

    You must create the account before protecting the clients. AutoUpdate will use the preconfigured account (and not create one with another suffix - this is normally only used on DCs). As these are local accounts the action must be performed for each client. Adding the required keys (by whatever method) should be pretty straight forward.

    The AutoUpdate service runs as LOCAL SYSTEM and therefore has no access to network resources. In order to download updates it must impersonate an account which does - this is the SophosSAU<COMPUTERNAME>0 user. Acting as this user AutoUpdate then accesses the CID using SophosUpdateManager (or whatever is specified in the policy).

    i guess more people should have expierenced this same problem

    Yes, but I know of no article or doc specifically addressing this (at least I haven't found one). So I wonder what's the official answer from Sophos, whether a defect has been raised or a suggestion accepted.

    Christian

    :22303
Children
No Data