I apologize if this question was already answered, but I’m under a bit of a time crunch, so thought I would post the question, then go out and search:
I have never used this product, but I have a customer that does, and he discovered that he can modify the Windows Scheduled Task on a client workstation, NOT logged in as an Admin user, and modify it so that he is able to change Admin passwords, and other various admin-level things from the Command Line, even as a “regular user.” Since the task is set to run as the Windows SYSTEM object, which does by default have those rights, my question is this: is there a better way / correct way to look at getting this product setup?
Thank you.
I’m afraid I don’t follow…what are you trying to accomplish?
Hey Jason, what the customer is afraid of is that “some user without admin credentials” will be able to modify that scheduled task and run their own code (for example, he was able to test the ability to force a change of the Domain Admin password). He would like to lock down that ability.
Okayyyy…
I’m not sure what this has to do with BigFix, but…a standard user cannot create tasks to run under the LocalSystem account. If an administrator creates a scheduled task to run under the System account, they need to take care that standard users do not have control over any of the scripts or data that the task relies upon. Similar to a Service being installed, it must not rely on user-controlled space (see also: recent vulnerabilities in the Steam gaming client).
If a standard user is able to create a scheduled task to run under the System account, then someone or something in your environment has modified the default Windows permissions badly. Bigfix could certainly help you in reimaging your machines, and ensuring their compliance against best-practice security checklists such as CIS, USGCB, or the DISA STIG.
Further, even the LocalSystem account on a workstation should not be able to change a Domain Admin account (or amy Domain acccount, for that matter). That should only be possible if the system in question is itself a Domain Controller, or if someone has badly mangled Active Directory permissions such that the Domain Computers group (or a group in which that workstation itself is a member) has much more than the default permissions.
Thank you Jason. That’s what I thought initially as well. I’m going to recommend my customer open a support ticket with HCL, and see if one of their techs can get him squared away.
Again, does this have something to do with Bigfix? Did someone use Bigfix to create this scheduled task you’re talking about?
I spoke to the customer this morning, and he is not so worried about the BigFix task as he is about the SYSTEM object having full control rights to Active Directory stuff. He was using the BigFix task as an example, and he added a line to the script (mistakenly, I presume) that changed all the passwords for his Domain and Enterprise Admin users.
I don’t yet know HOW he did that, but it turns out it isn’t a BigFix issue after all. Sorry to waste your time like that, but thank you for getting back to me so quickly
1 Like
Ok, I’m glad you have a handle on getting it sorted. To my knowledge there shouldn’t be a Bigfix entry in Scheduled Tasks, that may be something custom that they built at their site.
I’d check to see whether you can determine where that came from, keeping in mind that it could be an intrusion trying to disguise itself by using the name of a tool you know.
Awesome, thank you so much. I have another call with him later, and we will dig into that task.