
I would like to create a service account to use with APM. Currently I am uisng my domain account for testing which isn't good practice. What kind of rights do you need to give the account. I have found that some things do not seem to work unless I use my domain admin account. We are currently under a lot of pressure to reduce the number of domain admins. Is there documentation or guidelines anywhere on what rights are needed to get WMI and other queries APM uses? I have also noticed that if a local profile doesn't exist for the account you are using then it will not work until you have logged onto the server using that account (thereby creating a local profile). Is this by design? That seems cumbersome to me.
Take a look at this.
All I am getting out of that document is that the user must be a member of the administrators group on the server. The service account that I am using (on the domain) is part of the local admin group but does not work when using the remote WMI testing. However, my domain admin account does. Why?
All I am getting out of that document is that the user must be a member of the administrators group on the server. The service account that I am using (on the domain) is part of the local admin group but does not work when using the remote WMI testing. However, my domain admin account does. Why?
I don't have enough info to answer your question. Please open a ticket and reference this thread.
So what was the final result of this query? We're experiencing a similar situation.
I contacted pguenther directly on this and received the reply:
"Unfortunately I did not ever get this to work. We have shelved the APM module for now and are focusing on redesigning the rest of the system with EOC."
It seems to me that unless this issue has already been addressed in recent versions of APM, our ability to use the product in a secure manner could be crippled.
dayley,
What exactly are you trying to do?
We were shooting for an easy way to use a domain service account that wasn't a local administrator to monitor servers. We decided to use a domain account that was a local admin anyway, rather than modify the WMI settings on all the monitored servers.
Our domain admin's didn't like the idea of a service account having local admin access on domain controllers, so we figured out a way to work around this by splitting up the ownership of portions of the account password. This requires people on different teams to work together to configure a credential (each one supplies part of the password), but once the credential is in place, it can be used on DC's. It's not the ideal solution, but at least it prevents individuals from misusing the account for other purposes.
dayley,
Nice solution.
I am having a similar issue. I have created a local account on the Orion nodes I want to use APM for Windows Service checks. However, the account fails on a number of systems. I confirmed I can login interactively with that account and password. I also tested with the built-in administrator account and that works. But the created local account, which was added to the local Administrators group, will not work.
It's likely a group policy or local policy issue. I would check the Windows event log on the remotely monitored host to see what errors you're receiving. They may lead you to cause of the issue.
This appears to be UAC related. In 2008 R2, when UAC is left at the Default level, both RPC and WMI calls fail using a new local admin account, while the built-in works. When UAC is lowered to either the next level down or to OFF, the WMI and RPC calls work as they should.
In 2008 NON-R2, since UAC is only a check box, it does not work when ON and does work when OFF.