Closed stevie-sy closed 3 years ago
Thank you for the report. Yes you are correct, the documentation is not mentioning anything about this because for security reasons and other things (like modifying permissions inside system32
context), we do not want to encourage users to do so.
Right now we are working on a JEA profile for Icinga for Windows, which will terminate all requirements for permission handling and ensure a secure environment.
We hope a first experimental can be shipped with Icinga for Windows v1.6.0
I like the idea to ship a JEA profile (hope my colleagues, the server admins, as well). It will make a lot of things easier.
But because there still exist a thread in the communiy (https://community.icinga.com/t/invoke-icingacheckscheduledtask-unknown-unknown-tasks-task-not-found/7536) it seems there is still a need for a workarround until you build a solution like you wrote. Of course, it is not a nice solution to adjust the rights in the mentioned way.
Yes thats true - hopefully we get rid of all the permission problems with JEA. On a customer environment there is already a custom JEA profile running and all issues were gone regarding permissions.
As a workaround I honestly have no idea on how a good approach can look like. Modifying system32
folder content or using LocalSystem
for the Agent is something for security reasons I would not want to touch.
This should be resolved as we released v1.6.0 today, including support for JEA
From what the docs say there are no specific permisisons necessary. This isn't correct. But the good thing for you, the check works correctly. The problem is here the used PowerShell-Cmdlet "Get-ScheduledTask". Because to see all / the task you are looking for, it need (admin) permissions.
Usally the Icinga Agent is not running with an admin account. With a standard installation - like we are doing - the check is running as NETWORK Service. So if the Agent is triggering the check, he has to less permissions.
I did some tests ith PsExec and research in the web: I started a powershell with the user "network service"
PsExec.exe -i -u "nt authority\network service" powershell
and you will see diffrent results:Searching in the web delivers diffrent solutions and this deppends on the Windows Server version: The task information are set in C:\Windows\System32\Tasks and the registry. So you have to do this:
In my opinion there is no workarround. So you can only adapt your docs. But what I can give you is the following: My colleague knows MS SCOM very good. And he told me, that SCOM are using "Local System" to search for tasks. Maybe this is a way?