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

Problems with an Action-Account

Axel

Hello Everbody,

i have a Problem using Sophos Enterprise Console 4.0 in an Active Directory Structure.

We have installed and configured the Console with an single Action-Account. We use this Account to deploy the Endpoint Security and the Updates to the clients.

Since a couple of Month one (or more) of the Clients disable the Action-Account during the Updateprocess.

I checked the Settings of the Enterprise Console and the Action Account. (All looks fine).

The Computeraccount which disable the Account is not the same. When the Account get disabled,  i can't say which of our 450 Clients disabled the Account.

Unfortunatly our Permissions in the Active Directory end at our own OU-Container. We are only OU-Admins, not Domain Admins. When the account ist disabled i have to initiate a call to the office of the Domain Admins to get informations about the Computer Account. And the Domain Admins Office can only see which Clients is the first who get no Updates, not which one disabled the Account.

I want to create an new Action Account with an new Password, and deploy it to the Clients about the Enterprise Console. Is that a possible Way to solve this Problem?

Kindly regads


Axel

:5267


This thread was automatically locked due to age.
  • 0

    Hello Axel,

    actually, changing the policy might or might not help. If a workstation causes the account to be disabled it might use a policy with an outdated password. As it hasn't received the current policy it might also fail to process the new settings. The client might even not be in SEC. Creating a new account should help as only the "old" account will again be disabled and all correctly working clients should use the new account.

    I had a similar issue once. An old client (with outdated settings and which "knew" only the former management server) caused the account to be disabled. You didn't see anything in SEC of course (as it did not report) and as it wasn't managed there was no way to centrally supply it with a current policy. If your case is similar you can only tell from the domain which client is causing the account to be disabled. It is not properly protected and you'll have to identify it anyway. It might be possible to find it by scanning for an outdated Sophos version.

    Christian

    :5268
  • 0

    Hi,

    I would consider using two accounts, one with the administrative rights on the clients so it can create the scheduled task to deploy the software from SEC (it also needs to be able to log onto the Sophos management server machine) and another account for the updating policies.

    The account for updating, only needs read access to the distribution point and it's not an account I would want to put auto lock out on.  As users may see the account AutoUpdate is using, either in the GUI or in iconn.cfg, they might be inspired to attempt to guess the password, considering it a domain account that might give them more rights than their typical account has.

    The risk of a bad seed locking out a read only account to what is essentially a file share that could prevent all machines from updating doesn't seem right.

    Thanks,

    Jak

    :5272
Unfiltered HTML