So - who / what is this for? A bit of clarification & context would help.
So you can log into the Management Console with a local account (to the Core) if you wanted. You can name the NT-account anything you want ... we don't overly have a "Thou shallst name thy account XYZ" type rule.
As for permissions -- so the main thing to watch out for is that SOME features (such as IP Fingerprinting) require LOCAL ADMIN (wherever you run the console from), as network protocols behave differently depending on whether you do / don't have local admin (surprising, I know!).
As to what permissions you need on your CLIENTS ...? None really. Once the agent is installed, you can (theoretically) do "anything" (assuming you've got the rights & scopes for it).
So you could have "JoeSixpack" who has a basic NT/Domain account run a job on a remote device, which (due to our agent) runs as "Local System" & has those elevated privileges.
A better context / explanation for where your confusion / uncertainty is would help, as we can then try to better answer.
Basically this account exists on our system and management is asking why it is there, what it is used for and when can it go away. I'm assuming that it is an account put forth by our Corp brethren in their system and was brought into ours when they added us to the system. So I guess the plan of attack is to disable it and see what breaks and go from there as to how to fix it without giving away the master key.
Right - gotcha.
So the only account we put down by default is "LANDeskComPlus" (as a temporary stop gap) - because we HAVE to have "some account" for the COM+ identity to run as. Other than that, nothing really by default.
Things for you to check (from a "breaking" perspective):
- Scheduler service -- primary identity (i.e "who the service runs as").
- Scheduler service - "additional credentials" (need to access via "CONFIGURE SERVICES").
- COM+ identities for the 2x "LANDesk" objects (this needs to be just some AD-service account without any special creds, so we can query AD).
- The "Who you connect to the LDAP-directory"-account as / with in the USER MANAGEMENT tool ... (click on the picture for the full size version).
- You *COULD* do a string-search through the IIS-logs (say - "the last 7 days' worth of logs") to see if anyone / any script is using that account to talk to a www-service (for things like this -- Getting Started with the MBSDK (Example Scripts Included) ) for instance ... that's about all that comes to mind.
... otherwise, yeah ... disabling & seeing "what breaks" / who complains is a good enough way. That should help