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.
Parents
  • 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
Reply
  • 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
Children
No Data
Unfiltered HTML