BES Client Service Acccount

Usage and Config Platform
1

(imported topic written by EduardoBarbosa)

Hi,

I’m using TEM to deploy remotely an Backup Plan xml file to be imported on endpoints using a third party tool.

My problem is that this is done using command line tools that need user context to define the plan owner.

Having the BES Client Service running on the default system account does not work and the credentials are lost on the importation.

If I change the service to another local admin account everything works fine.

Can anyone tell me:

1-What are the implications on running the service on another Admin account ?

2-Any plausible alternative to make this without external tools like psexec to run under another context ?

Thanks in Advance

Eduardo Barbosa

2

(imported comment written by SystemAdmin)

Running the BES Agent as anything other than LOCAL SYSTEM will limit what it can do as the LOCAL SYSTEM account has special privileges set on the machine.

If you have to run an action as a user there is a RunAsCurrentUser executable you can use, checking if the user is an admin before would be a good idea from what you describe though.

http://www-01.ibm.com/support/docview.wss?uid=swg21506033

3

(imported comment written by EduardoBarbosa)

Hi AlanM,

Thanks for your feedback.

I know the RunAsCurrentUser utility, but has the documentation says: “RunAsCurrentUser, can run commands on Windows systems using the credentials and local context of the currently logged on user.”

And I need the relevance code to be executed even if no user is logged in.

Also the user currently logged in may not have right to make the necessary task.

Do you know any documentation that specifies what limitations exists when a non loca system account is used ?

Thanks in Advance

Eduardo Barbosa

4

(imported comment written by SystemAdmin)

Problems that I know of that can happen without the right privileges (some can be set to accounts some cannot):

  • AD Information (active directory inspectors)
  • User Detection (user, current user, local user inspectors)
  • Program execution scanning (processes inspectors)
  • Security information (sid, dacl, sacl etc inspectors)
  • Launching ClientUI as other users
  • Many more…

And many more. The client will limp along doing what it can but you will just get many errors on content.

We don’t have the ability to run as an arbitrary user as we don’t have the account information to “log on” as that user. There may be ways to do this but nothing that is currently available.