Role-based access control (RBAC)
Regulate access to various functionality based on user roles and permissions. This would include granular access to capabilities such as:
- Logon to KBE
- Access to specific production images
- Server/workstation roles
- Samba share access
- Differentiate between access to deploy images, and access to log into connected machines as an admin.

-
Daniel Castro commented
Can we at least have an "operator" role with some basic functionality?
-
Carsten Buscher commented
Any idea when this feature will be available?
-
Anonymous commented
Any updates on this?
-
Anonymous commented
Great Idea! Like someone else suggested, even just giving the "Read-Only Admin" the ability to capture user states would be very helpful.
-
Aamir commented
It just be nice if there was a way to customize the roles for the techs that use the SDA. For example, we have about 19 RSA's and they all have their own techs (about 30+) using Kace. Just like the SMA, I like to customize what they can do. Give them only certain scripted installs to see/edit, create/edit post install tasks but not able to delete, not able to capture their own image, etc. ReadOnlyAdmin is there, but they'll just come back and ask for edit rights anyways. Giving them some edit rights will be better.
-
AdminChris Blake (Admin, Quest KACE) commented
I could see value in giving a tech access to Boot Actions, and almost nothing else so they could load a list of MAC's.
-
Brian commented
Any update on when this is going to be rolled out? Would be very useful...
-
David Coe commented
setup an account that has configurable rights to the Samba share folders,
or allow Ldap accounts have configurable access to the Samba ShareIt would be nice to give one of my team members access to the samba share without having to give them the Admin Account information.
-
Yin Etzel commented
We what to give our Techs the right to pull down an image only. So since the above comment by Alex Au Yeung is over 11 months old, have we a version that has the integrated K1-style permissions released yet? If so, which version?
-
Anonymous commented
Looks like it didn't make it into the 3.7 update...
-
Michael commented
Looking forward to this added feature. Hopefully it will show up in 3.7 Would vote more on this if I had them.
-
bruce commented
It would be nice to be able to restrict the imaging of server hardware. That way, if someone tried to image a server, they would have to have seperate credentials to do so.
Even further, be able to use the K1's smart labels or some other mechanism , maybe even just IP range, to restrict who has what access to imaging certain groups of machines.
-
BlaiseG commented
Anxiously awaiting this feature...
-
J. Bautista commented
-
Paul Kochie commented
The only thing I'd like my "ReadOnly Admin" users to be able to do is capture User States.
-
Jon commented
Our desktop team uses the PXE features of the k2 to logon to the KBE to image machines. The problem being that they then have access to all of the images stored on the k2. I would be nice to have the ability to define roles on the k2 and assign them certain functionality and access to certain production images.
-
Karl Ng commented
I would like the ability to create roles in the k2000 and also in the rsa. I would like my techs to be able to vnc into a scripted install and kick off there installs without having to physical be in front of the machine. The techs may have 50 machines to image and it would be benefical for them to remotely manage them. I do not want to give them access to the k2000 because they would have the ability to change the scripted installs or alter, delete or change the operating systems, boot files, etc.
-
Kenny Tu commented
This would help me a lot.
-
KFortney commented
This would really help make things more granular in our organization. I am hesitant to assign work for parts of the server when other parts will be vulnerable to people who do not need access to server settings and the like.
-
Nicolas commented
In our environment, the IT team and the R&D team have to deploy OSes. But they not have to deploy the same environments.