Sub-Administrator Level Roles
Allow for a role that has access only to certain machines and the ability only to create and modify their SW distributions, but have access to shared distributions. An alternative would be allowing more than one organization to share software distributions and other resources
We are excited to announce that version 8.0 of the KACE Systems Management Appliance (SMA), is almost ready for the Beta/Release Candidate program. The Beta program is invaluable in making sure that we are shipping the highest quality product we possibly can. If you are interested in participating in the Beta/Release Candidate program, please email:
Note that there are a few pre-requisites for participants:
-Must be on SMA v7.2
-Must be on 7.1 + agents with no orphans
-Must be willing to tether with the Release Candidate Team
-Must be willing to schedule a specific date and time that works for you
Please be sure to mention that you are specifically interested in Role Based Access
Thank you in advance!
The KACE Product Management Team
I too would like to see this implemented and a status given please. How many votes does it take to be considered? I am new to Kace but it seems this has been out there since 2010.
My vote has been placed.
Been 17 months since we've heard anything about this. What's the plan?
I was in a meeting yesterday. I was told that we are going to start building SCCM servers starting in August. During the meeting I was constantly saying "Kace can do that"/"Kace can do this". Unfortunately the only thing I was not able to say "Kace can do that" was these sub-admin roles.
We have 50+ techs that will need access to patch their machines, and deploy software to their machines. There is currently a label set for their machines. I would be great to give them access to just their machines.
I saw that the last update was a year ago. I'm hoping this is coming soon so that I do not need to redo my entire environment in moving to SCCM. Please keep up posted.
Will this include the ability to assign admins responsibility for specific things? For example, I need an admin in each department that will be responsible for just creating and deleting accounts. I don't want them to have access to all of the features as it will be hard to track any changes that they make.
Not sure if there is a date assigned for this? i know it was set for this year not sure when this year. This is happening?
Any update on this? Thank you
Chris Olson commented
Agreed, absolutely required. Was looking at buying KACE, but I think this kills it unless it's on a short-term (<9 months) roadmap.
@Admin, is there an ETA of when this will be available? Thank you
Renee D. commented
We really need this option. Please look at this as soon as possible.
Matthew Shephard commented
We are needing to allow Project Managers to view their site's tickets/reporting but only with access to tickets with a given "Location" (custom field) or computer name. At the moment, my only options are to deny the request or grant read-only admin permissions, allowing them to see EVERYTHING.
I agree that a more granular rights system would be INVALUABLE!
Individual rights (read, modify, delete) based on labels would be a major improvement.
Patrick Kelley commented
I'd love to have the ability to have my techs be able to add or change assets but NOT delete them. Right now it's all or nothing.
Uma Shankar commented
This is a critical requirement to meet auditing, security and manageability needs. Also all other vendors Altiris, LANDESK and JAMF have this feature.
Andreas Gruenert commented
I truly hope that this idea won't get forgotten, because Dell KACE may want to sell K1000 with the organization feature instead. Having label based (sub-administrator) permissions would make this already great product massively better. We could manage all branch offices supervised by their own IT team with one organization and we could move tickets from the branch queues to the main queue which is not possible over the "organization boundary". Version 5.5 or 6.0? Promise?
Terry Reece commented
This would be extremely helpful. Many of our Org's on our K1000 are split up by contract, but there is further separation of systems by who manages those, what security plan they fall under. It would be great to be able to have more granularity with permissions so we can give users more tools to manage only their systems through the K1000. Restricting permissions by label would be the best thing since sliced bread!
This is the details concering a support ticket I submitted to KACE
When creating scripts we are setting them to disabled yet you can still see them and run them in the Run Now Tab. We scaled our security roles so regular IT staff only have read access to the Run Now tab but all of the scripts are showing up in their wether we have disabled them or not. We have also tried marking the script as Draft, Template, or example but no matter what we select the IT staff still have access to run them. This is extremely concerning as the restart windows script is disabled yet they have access to run that, and there is no way that we know of to hide the Deploy to All machines check box. We have over 10,000 pcs and if someone would deploy that script to all of them the consequences are huge. We currently have everyone set to read only so that run now button is gray'd out but we want them to have access to run scripts, but not run them agains all machines, just individual computers or labels. Is there a way to hide the Deploy to all check box or why doesnt disabling the script disable it from the run now drop down. Please advise ASAP.
Received this response
Sub-level role configuration is currently not an option within the kbox. I've also checked to see if it would be something we can customize your kbox with, but it doesn't look like it. The current roles are only available to provide read/write functionality to each sub-section of each category within the kbox and that is it. So either these agents will have Read access to all scripts or Read/write access to all scripts and there isn't a way to setup (at this time) to specify what types of scripts/reports/patches/etc.. an agent can have access to or control over. There are a few similar enhancement requests on the uservoice page asking for sub-level role munipulation capabilities. The best one I can find based on your request is this one here:
which could use some better or more specific feedback like what you have submitted to this ticket. Its under review at the moment without a scheduled time frame as to when it will be available in a future version. I'm guessing (based on the amount of votes it has) it will be available in either the 5.5 or 5.6 release. I've already looked at the information related to the 5.4 release and have not found any current updates that would indicate this type of request being included at this time.
Since the impact of running these is so great I would feel this be highly beneficial if this is addressed in a future update.
As we look to integrate servers into the KACE systems management fold, we certainly need to segregate these items administratively. Sufficient capacity exists on a single K1200 appliance to handle the expected load. I shouldn't have to deploy a 2nd appliance just for servers to achive this segregation.
Unfortunately, K1200 organizations aren't an entirely clean choice to achieve administrative segregation as the KACE agent must be installed on the server hosting our file replication share and will forever live in the 'clients' organization.
Administrative isolation of servers via smart label would allow us to leverage our existing infrastructure while giving us the flexibilty to segregate systems and the people that manage them.
Jeff Brown commented
In regards to more granular security, we would like to see an option to only allow certain server admins to patch certain machines. For example, we want to create a label for our servers and set up a detect job on them. We do NOT want the helpdesk staff to have the ability to do any patching on the server labels. This would be a great feature to see.
And it could be also nice if there are possible to give rights for normal users to write articles. Now only admins can write them and if some normal user wan't to share his solution he/she can't do it.
Thatcher Deane commented
This feature as painted in the comments would be very helpful to us as we are soon taking responsibility for a new area of our organization which has far higher security and other requirements than the rest of our organization. We too have twice accidentally pushed stuff to wider scope then intended. Our CTO was not happy and was almost ready to shutdown all use of KBOX scripting.