Permission to setting up Metricbeat on Windows


(Ronan Luiz) #1

I'm setting up Metricbeat (Version: 5.1.1) on a Windows Server 2008 R2 environment, but to be able to collect data from all the processes running on the server it was necessary to configure the service to run a user with administrator privileges. Currently, if the service runs with the Local Service user or Network Service only the process of the service itself (metricbeat.exe) is collected.

I would like to know if the service only works with admin user, because in the Metricbeat documentation this information is not clear. If there is no need for an administrator user, what kind of permission I need to grant to a local or domain account to be able to collect data for all processes?

Thanks very much!


(Andrew Kroh) #2

The user needs to have the SeDebugPrivilege.

When Metricbeat starts up it will log info about the privileges it has.

2017/01/18 17:12:53.930069 system_windows.go:34: INFO Metricbeat process and system info: {"OSVersion":{"Major":6,"Minor":2,"Build":9200},"Arch":"amd64","NumCPU":2,"User":{"SID":"S-1-5-21-3541430928-2051711210-1391384369-1001","Account":"vagrant","Domain":"VAGRANT-2012-R2","Type":1},"ProcessPrivs":{"SeBackupPrivilege":{"enabled":false},"SeChangeNotifyPrivilege":{"enabled_by_default":true,"enabled":true},"SeCreateGlobalPrivilege":{"enabled_by_default":true,"enabled":true},"SeCreatePagefilePrivilege":{"enabled":false},"SeCreateSymbolicLinkPrivilege":{"enabled":false},"SeDebugPrivilege":{"enabled":true},"SeImpersonatePrivilege":{"enabled_by_default":true,"enabled":true},"SeIncreaseBasePriorityPrivilege":{"enabled":false},"SeIncreaseQuotaPrivilege":{"enabled":false},"SeIncreaseWorkingSetPrivilege":{"enabled":false},"SeLoadDriverPrivilege":{"enabled":false},"SeManageVolumePrivilege":{"enabled":false},"SeProfileSingleProcessPrivilege":{"enabled":false},"SeRemoteShutdownPrivilege":{"enabled":false},"SeRestorePrivilege":{"enabled":false},"SeSecurityPrivilege":{"enabled":false},"SeShutdownPrivilege":{"enabled":false},"SeSystemEnvironmentPrivilege":{"enabled":false},"SeSystemProfilePrivilege":{"enabled":false},"SeSystemtimePrivilege":{"enabled":false},"SeTakeOwnershipPrivilege":{"enabled":false},"SeTimeZonePrivilege":{"enabled":false},"SeUndockPrivilege":{"enabled":false}}}
2017/01/18 17:12:53.933979 system_windows.go:42: INFO SeDebugPrivilege is enabled. SeDebugPrivilege=(Enabled)


(Ronan Luiz) #3

Thanks for the feedback!

I checked the logs and it was registered that SeDebugPrivilege is enabled, however, in the log the information "Account" was registered with the user account that I'm logged on the server (Administrator) e not with local account for which the service was configured to run. The issue has not been resolved yet.

Do you have any idea what I can do?


(Andrew Kroh) #4

How did you start metricbeat?

Did you run it as a service? If you don't want to start it using the local system account, then you can use the services.msc to modify the account that the metricbeat services runs as.


(Ronan Luiz) #5

Hello, Andrew.

Again, thanks for the feedback.

Yes, I am running metricbeat as a service, and the account that it runs has already been changed by a non-administrative user account in services.msc. I have also granted this non-administrative user account the SeDebugPrivilege permission through Local Security Policy "Debug programs".

I suspect that there is some domain policy that is not allowed to grant the "Debug programs" policy, but I have not yet been able to confirm it, and as I mentioned in the last post, the logs of the service were registered in the Administrator account, not the account I configured For the service to run.

Do you know how you can help me with some other tip?


(Andrew Kroh) #6

It sounds like the service is not running properly as the user designated in services.msc. The log message in Metricbeat should show the same account as what you have configured.

Once it's running as that correct user then you can debug the SeDebugPrivilege problem. There is a GPO object that controls who has SeDebugPrivilege.


(system) #7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.